Composition

Composez les surfaces du produit à partir de petites primitivesLien vers la section

Les composants PyColors UI sont intentionnellement petits.

Ils ne sont pas conçus pour posséder tout votre flux de produits.

Ils sont conçus pour être composés de surfaces de produits claires et maintenables:

• tableaux de bord
• pages de paramètres
• panneaux de facturation
• formulaires
• tableaux
• superpositions
• Outils d'administration
• états vides et d'erreur

L’objectif n’est pas de créer le plus grand composant possible.

L'objectif est de composer des primitives plus petites en interfaces qui restent compréhensibles au fur et à mesure que le produit grandit.

Pourquoi la composition compteLien vers la section

La plupart des systèmes d'interface utilisateur commencent à nettoyer et deviennent fragiles plus tard.

La cause habituelle n’est pas le design.

C’est la stratégie d’abstraction.

Les produits deviennent difficiles à maintenir lorsque les équipes :

• créer un composant géant pour chaque fonctionnalité
• dupliquer le même modèle de mise en page à travers les pages
• mixer la logique métier dans les primitives UI
• ajouter des variantes uniques au lieu de composer des états
• Cacher les décisions des produits derrière des accessoires peu clairs

La composition empêche cela.

Il vous permet de garder les primitives réutilisables tout en construisant de vraies expériences SaaS.

Le modèle de compositionLien vers la section

PyColors utilise un modèle mental en couches.

Principes de compositionLien vers la section

Composition des pagesLien vers la section

Une page SaaS de production a généralement quatre responsabilités.

Cela permet de garder la page lisible.

La page coordonne l'intention du produit. Les composants rendent les pièces.

ExemplesLien vers la section

Ces exemples illustrent comment la composition transforme de petites primitives d'interface utilisateur en surfaces réelles de produits.

Chaque exemple met en évidence comment la structure, l'état et l'intention de l'utilisateur sont organisés pour créer des interfaces évolutives, prévisibles et faciles à maintenir.

Ne vous concentrez pas uniquement sur les composants. Concentrez-vous sur la façon dont la page coordonne le comportement.

Exemple : page de paramètresLien vers la section

Une page de paramètres n'est pas un composant.

C'est une composition de surfaces, de navigation, d'entrées et de confirmations.

export function SettingsPage() {
  return (
    <div className="space-y-6">
      <SettingsHeader />

      <Tabs defaultValue="profile">
        <TabsList>
          <TabsTrigger value="profile">Profile</TabsTrigger>
          <TabsTrigger value="security">Security</TabsTrigger>
          <TabsTrigger value="billing">Billing</TabsTrigger>
        </TabsList>

        <TabsContent value="profile">
          <ProfileSettingsCard />
        </TabsContent>

        <TabsContent value="security">
          <SecuritySettingsCard />
        </TabsContent>

        <TabsContent value="billing">
          <BillingSettingsCard />
        </TabsContent>
      </Tabs>
    </div>
  );
}

Cette page utilise des primitives, mais la signification du produit provient de la composition :

• onglets séparés préoccupations
• contenu du groupe de cartes
• Les entrées collectent les valeurs
• Les dialogues confirment les actions destructrices
• alertes communiquent les états bloquants

Exemple : panneau de facturationLien vers la section

L’interface utilisateur de facturation a besoin d’une hiérarchie claire car elle affecte la confiance et les revenus.

export function BillingPanel() {
  return (
    <Card>
      <CardHeader>
        <CardTitle>Current plan</CardTitle>
      </CardHeader>

      <CardContent className="space-y-4">
        <Badge variant="success">Active</Badge>
        <p className="text-sm text-muted-foreground">
          Your subscription is active and renews next month.
        </p>
        <Button>Manage billing</Button>
      </CardContent>
    </Card>
  );
}

Les primitives restent simples.

La couche de produit décide:

• Ce que signifie l'état de facturation
• quelle action est disponible
• quelle copie rassure l'utilisateur
• quand l'accès doit être fermé

Exemple : page lourde de donnéesLien vers la section

Les pages riches en données ne devraient pas rendre la table responsable de tout.

export function ProjectsPage() {
  return (
    <div className="space-y-6">
      <ProjectsHeader />
      <ProjectsToolbar />
      <ProjectsTable />
      <ProjectsPagination />
    </div>
  );
}

La table affiche les lignes.

La page coordonne :

• filtres
• État de chargement
• état vide
• Erreur de récupération
• pagination
• actions en ligne

Workflow de compositionLien vers la section

Quand extraire un composantLien vers la section

Extraire un composant lorsque :

• La structure visuelle se répète
• le composant a une responsabilité claire
• il rend la page plus facile à lire
• l'abstraction ne cache pas la logique importante du produit

Ne pas extraire lorsque :

• Le composant n'existe qu'une seule fois
• l'abstraction crée trop d'accessoires
• la composante mélange des responsabilités non liées
• le nom ne décrit pas un concept clair

Quand créer un PatternLien vers la section

Créez un Pattern lorsque le besoin répété inclut un comportement.

Exemples :

Un modèle peut inclure plusieurs primitives, des règles d'état, des règles de copywriting et des conseils d'accessibilité.

Préférez/évitezLien vers la section

Liste de contrôle de la compositionLien vers la section

Avant d'expédier une surface d'interface utilisateur composée, confirmez:

• La page a un objectif utilisateur clair
• chaque composant a une responsabilité claire
• Les tokens sémantiques sont utilisés pour les rôles visuels.
• les états de chargement, de vide et d'erreur sont traités
• Les actions ont un feedback clair
• Les overlays ne sont utilisés qu'en cas de besoin
• comportement répété est déplacé dans un motif
• La logique métier n'est pas cachée dans les primitives
• la mise en page a toujours du sens sur mobile

Prochaines étapesLien vers la section