Structure du projet · Documentation

NA-AI LandingStructure

Comprendre l'architecture avant de réécrire l'interface utilisateurLien vers la section

NA-AI Landing s’organise autour d’une simple séparation :

Contrôle du contenu. Les sections rendent les blocs de produits. Les composants de mise en page encadrent la page. PyColors UI fournit des primitives.

Cela permet de garder la personnalisation propre, prévisible et plus facile à maintenir à mesure que la page de destination évolue.

La plupart du contenu du produit peut être mis à jour à partir de:

src/@data

avant de toucher la mise en œuvre visuelle.

La structure est optimisée pour une itération rapide.

NA-AI Landing sépare le contenu, les sections, la mise en page et les primitives de l'interface utilisateur afin que vous puissiez personnaliser le positionnement et l'image de marque sans reconstruire la base.

Guide de personnalisation

Paiement unique — Accès instantané après achat

Idée clé

Le modèle est conçu pour que le contenu du produit puisse évoluer sans réécrire constamment la base visuelle.

Vue d'ensemble de l'architectureLien vers la section

Structure pilotée par les données

Contenu, prix, navigation, FAQ, témoignages et copie CTA en direct dans des fichiers de données centralisés.

Sections composables

Les blocs de page d'atterrissage sont isolés en sections de présentation réutilisables.

primitives d'interface utilisateur partagée

La couche visuelle est alimentée par l'interface utilisateur PyColors et les tokens de conception sémantique.

Flux de travail de personnalisation rapide

L'architecture donne la priorité à l'image de marque, au positionnement et à l'itération rapide des produits.

StructureLien vers la section

contact.ts

cta.ts

customers.ts

faq.ts

features.ts

footer.ts

hero.ts

index.ts

integrations.ts

navbar.ts

not-found.ts

pricing-table.ts

pricing.ts

globals.css

layout.tsx

page.tsx

not-found.tsx

robots.ts

sitemap.ts

manifest.webmanifest

Flux d'architectureLien vers la section

architecture-flow.txt

src/@data
  ↓
components/sections
  ↓
components/layout
  ↓
@pycolors/ui + @pycolors/tokens

Couche de données

The data layer owns structured content, pricing values, navigation labels, FAQ items, testimonials, and section configuration.

Content ownershipPricing configurationNavigation structureFAQ and testimonials

Répertoire des donnéesLien vers la section

Fichier	Responsabilité
`hero.ts`	Copie de héros, CTA, badges et contenu visuel
`features.ts`	Cartes de fonctionnalités et contenu de section d'analyse de l'IA
`integrations.ts`	Catégories d'intégration et cartes d'intégration
`pricing.ts`	Plans de tarification et de facturation
`pricing-table.ts`	Lignes de comparaison des prix
`customers.ts`	Témoignages et témoignages clients
`faq.ts`	FAQ contenu
`contact.ts`	Copie du formulaire de contact et options d'objectif
`cta.ts`	Section de conversion finale
`navbar.ts`	Liens de navigation
`footer.ts`	Liens de pied de page et copie de pied de page

Règle de personnalisation

Changer les données en premier. Modifiez les composants de la section uniquement lorsque la structure actuelle ne prend plus en charge l'histoire du produit.

Ajouter une nouvelle sectionLien vers la section

Créer le fichier de donnéesLien vers la section

terminal

touch src/@data/use-cases.ts

Créer le composant de sectionLien vers la section

terminal

touch src/components/sections/use-cases.tsx

Composez la section à l'intérieur de la pageLien vers la section

src/app/page.tsx

import { UseCasesSection } from "@/components/sections/use-cases";

export default function Page() {
  return <UseCasesSection />;
}

Règles d'architecture recommandéesLien vers la section

Préférez

contenu data-driven
composants de petite section
primitives partagées de PyColors
tokens sémantiques
UI spécifique au modèle isolé

Éviter

hardcoding toutes les copies dans les composants
Mettre la logique backend dans les sections
dupliquer les enveloppes de mise en page
supprimer les importations de tokens
forking des primitives d'interface utilisateur partagées inutilement

Pourquoi cette structureLien vers la section

Au fur et à mesure que les pages de destination se développent, les problèmes proviennent généralement de frontières peu claires:

copie mélangée avec la logique de mise en page
Sections dupliquées
Espacement incohérent
Valeurs de prix dispersées
Des actifs SEO déconnectés
remplacements visuels incontrôlés

Cette structure réduit ces problèmes en gardant les responsabilités séparées dès le début.

Principe de mise à l'échelle

Une bonne architecture de landing page devrait rendre l’itération moins chère au fil du temps, pas plus fragile.

Questions courantesLien vers la section

Prochaines étapesLien vers la section

PersonnalisationMettre à jour la copie, les sections, le branding, les métadonnées SEO et les ressources.DéploiementDéployer la page de destination à la production après la personnalisation.