Due lezioni che ho imparato realizzando componenti React

Due lezioni che ho imparato realizzando componenti React


Ecco un paio di lezioni che ho imparato su come non costruire componenti React. Queste sono cose che mi sono imbattuto negli ultimi due mesi e ho pensato che potrebbero interessarti se stai lavorando su un sistema di progettazione, in particolare uno con un sacco di decisioni tecniche legacy e un sacco di debito tecnologico sotto il cappuccio.

Lezione 1: Evita il più possibile i componenti figlio

Una cosa su come lavorare su un grande sistema di progettazione con molti componenti è che il seguente modello alla fine inizia a diventare problematico molto rapidamente:

Titolo

Questo è un po ‘di contenuto

 

Le parti problematiche sono quei componenti figlio, Card.Body e Card.Header. Questo esempio non è terribile perché le cose sono relativamente semplici – è quando i componenti diventano più complessi che le cose possono ottenere disossate. Ad esempio, ogni componente figlio può avere un’intera serie di oggetti di scena complessi che interferiscono con gli altri.

Uno dei miei maggiori punti deboli è con i nostri componenti Form. Prendi questo:

Sto semplificando considerevolmente le cose, ovviamente, ma ogni volta che un ingegnere vuole posizionare due pulsanti uno accanto all’altro, importano Form.Actions, anche se non c’era un Modulo sulla pagina. Ciò significa che tutto ciò che è all’interno del componente Modulo viene importato e ciò è in definitiva negativo per le prestazioni. È solo una cattiva implementazione della progettazione del sistema.

Ciò rende le cose ancora più difficili durante la documentazione dei componenti perché ora dovrai assicurarti che anche ciascuno di questi componenti figlio sia documentato.

Quindi, invece di rendere Form.Actions un componente figlio, avremmo dovuto renderlo un componente nuovo di zecca, semplicemente: FormActions (o forse qualcosa con un nome migliore come ButtonGroup). In questo modo, non è necessario importare sempre il modulo e possiamo mantenere i componenti basati sul layout separati dagli altri.

Ho imparato la mia lezione. Da qui in avanti eviterò del tutto i componenti figlio dove posso.

Lezione 2: assicurati che i tuoi oggetti di scena non siano in conflitto tra loro

Mandy Michael ha scritto un ottimo articolo su come gli oggetti di scena possano imbattersi l’uno nell’altro e causare conflitti di ogni genere, come in questo esempio di TypeScript:

interfaccia Props {hideMedia ?: boolean mediaIsEdgeToEdge ?: boolean mediaFullHeight ?: boolean videoInline ?: boolean}

Mandy scrive:

Lo scopo di questi oggetti di scena è quello di cambiare il modo in cui l’immagine o il video viene riprodotto all’interno della scheda o se il supporto è reso a tutti. Il problema nel definirle separatamente è che si finisce con un numero di flag che attivano / disattivano le funzionalità dei componenti, molte delle quali si escludono a vicenda. Ad esempio, non puoi avere un’immagine che riempia i margini se è anche nascosta.

Questo è stato sicuramente un problema per molti dei componenti che abbiamo ereditato nei sistemi di progettazione del mio team. C’erano un sacco di componenti in cui oggetti di scena booleani avrebbero fatto comportare un componente in tutti i modi dispari e inaspettati. Durante lo sviluppo abbiamo persino fatto apparire tutti i tipi di bug nel nostro componente Card perché gli ingegneri non sapevano quali oggetti di scena attivare e disattivare per un determinato effetto!

Mandy offre la seguente soluzione:

type MediaMode = 'hidden' | 'edgeToEdge' | Interfaccia 'fullHeight' Puntelli {mediaMode: 'hidden' | 'edgeToEdge' | 'fullHeight'}

In breve: se combiniamo tutte queste opzioni nascenti insieme, abbiamo un’API molto più pulita che è facilmente estendibile ed è meno probabile che causi confusione in futuro.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *


Categorie




Related posts





Social Share


Feedback

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...





Scroll Up