Com es crea un kit d'interfície d'usuari React escalable

Foto de Blake Wheeler

A Travix tenim un sol producte amb 4 temes diferents. Cada tema és una marca independent i cada marca té uns quants llocs web. Actualment hi ha més de 45 llocs web actius a la nostra plataforma.

Dues de les nostres 4 marques diferents

Hi ha prop de 40 desenvolupadors frontals que treballen al producte perquè tot funcioni i és bastant difícil mantenir la base de codi i el disseny coherents.

Si esteu treballant en un gran projecte React, és probable que hi hagi algun tipus de kit d’interfície d’usuari integrat a la vostra base de codi. El component general del botó, una implementació modal genèrica, un calendari que utilitzeu tot el temps, components generals que no contenen cap lògica empresarial.

L’objectiu principal d’aquest article és ajudar-vos a desenvolupar i organitzar el vostre kit d’interfície d’usuari perquè pugueu millorar el vostre procés de desenvolupament i la coherència del disseny del vostre projecte.

Com us podeu imaginar, aquesta biblioteca no només depèn del vostre equip de desenvolupament. També heu d’implicar els dissenyadors. Tant se val que siguis hàbil o quines tecnologies triïs quan el teu equip de disseny sol·liciti 9 botons diferents i 22 mides de lletra.

Si teniu sort, no serà un problema enorme. Ara és habitual que els equips de disseny tinguin una guia d’estil. Però si la sort no és la vostra millor habilitat, podeu tenir alguna cosa com grayCantBeLighterThanThis nom variable al vostre tema (història real).

tecnologia

Com suggereix el títol, estem utilitzant React per crear la nostra aplicació. La majoria dels consells d’aquest article es poden utilitzar fàcilment en diferents arquitectures perquè tenen eines i biblioteques similars.

Llibre de contes

El llibre de contes serà el vostre pati de desenvolupament i la vostra galeria de components. És útil considerar el vostre component com un paquet aïllat i separar-lo del producte per poder tenir propietats comunes i ben descrites.

Component no reutilitzable

Una implementació específica d’un botó

Component genèric

Implementació genèrica d'un botó

Storybook també és ideal per proporcionar documentació. Hi ha un complement anomenat storybook-addon-info que afegeix automàticament el component JSX i la descripció del tipus de suport a la pàgina del component.

L'execució de tota l'aplicació probablement només farà uns quants passos i serà molt lent. El llibre de contes sol ser més ràpid per començar, de manera que podeu desenvolupar-lo més ràpidament. Podeu desenvolupar els components de la interfície d’usuari imitant totes les propietats (els lliscadors de complements de llibres de contes són ideals per a la burla) en un parc infantil completament aïllat sense executar l’aplicació principal.

Components dissenyats

També necessitareu alguna cosa per tractar temes. Abans hem provat variables CSS pures i ha funcionat bé. El paquet conté dos fitxers CSS, un amb el component de biblioteca i un altre per a la declaració de variables. Si teniu més d’un tema, només heu de canviar el fitxer de temes i hauria de funcionar.

Temes amb CSS pur

A la nostra nova biblioteca, vam decidir els components d’estil. Ja ofereix una solució temàtica i CSS a JS funciona bastant bé amb React. També configuren les àrees CSS per defecte, que resol el problema més gran en informàtica, el nom.

Això us pot ajudar a evitar anul·lacions CSS inesperades i evitar que els desenvolupadors anul·lin deliberadament les regles CSS. El seu comportament de components està lligat a la seva pròpia definició de propietat i ningú no pot anul·lar els estils a nivell mundial.

A més, podeu definir millor les regles condicionals als vostres estils, ja que no cal que amplieu les classes CSS ni les gestioneu al vostre element. Bàsicament, esteu passant accessoris a un component de vista i aquest component el pot utilitzar per manejar casos de vora.

Tema seleccionat disponible per utilitzar-lo als nostres components

A Travix vam crear un complement de llibre de contes per canviar fàcilment el tema. Si heu jugat amb Styled Components ThemeProvider, sabreu que bàsicament hem de canviar la propietat del tema i això funciona com un encant. Aquest complement ens ajuda a provar totes les marques durant el desenvolupament i ajuda els propietaris de productes (OP) i els dissenyadors a validar la implementació.

Complement del selector de temes

mecanoscrit

Hi va haver pocs problemes per implementar TypeScript. Hem passat almenys dues setmanes actualitzant la nostra solució per donar-hi suport i dues setmanes més migrant-ho tot. Si el voleu utilitzar, us recomano encarar el projecte des de zero amb TypeScript.

Però definitivament paga la pena i l’autocompleció de trets i valors ajuda al desenvolupament. També us ajuda a definir millors contractes per al vostre component, ja que qualsevol definició de tipus de propietat exòtica prendrà llum vermella durant el procés de verificació.

Compleció automàtica TypeScript

Eslint

Per garantir la coherència de la base de codi, tenim una configuració d’Eslint molt estricta. Hem decidit ser estrictes aquí per no perdre el temps en revisar petits detalls del codi.

El nostre linter s'executa automàticament abans de cada inserció i s'ajusta una correcció automàtica a l'última confirmació. També funciona al nostre ordinador CI. Per tant, si algú decideix ometre la validació, fallarà durant la compilació.

Procés de desenvolupament

El més important per a nosaltres no era la tecnologia en si, sinó el procés. Hem dedicat molt de temps a mantenir-los el més estrictes possible per garantir la qualitat de la biblioteca a llarg termini. Això és molt important en una gran empresa perquè els desenvolupadors marxen, els desenvolupadors s’uneixen, però la vostra base de codi resistirà la prova del temps.

Sol·licitud d'extracció de RFC

RFC significa "Sol·licitud de comentaris". En aquesta sol·licitud d'extracció no s'implementa cap línia de codi. Bàsicament, afegim un fitxer de reducció que descriu el nostre component. Utilitzeu casos, propietats, recordatoris, possibles efectes secundaris.

La vostra nova biblioteca l’utilitza tota l’empresa i hi ha molts casos majors i detalls menors que cal ajustar. Les sol·licituds pull poden convertir-se fàcilment en grans fils de discussió sobre si el component ha de ser un component HOC o RenderProps, composable o més estricte, controlat o incontrolat, etc. Per tant, RFC no us ajudarà, cap Perdre el temps implementant alguna cosa que es canviarà completament després de la revisió.

Revisió de la sol·licitud pull

La nostra revisió de la sol·licitud d’extracció requereix només uns quants passos automatitzats, tres aprovacions de desenvolupadors i les revisions de PO / designers. Si falla qualsevol d'aquests passos, no es fusionarà res.

Passos CI: - Executeu eslint i proves. - Comproveu que la cobertura del codi no disminueixi. - Generar un entorn de llibre de contes únic (també actualitza l'entorn quan cometeu alguna cosa nova).

Els desenvolupadors que revisin la vostra sol·licitud d'extracció només hauran de comprovar que la implementació compleixi la RFC ja aprovada i que el disseny sigui correcte.

Els dissenyadors i els gestors de comptes poden revisar la vostra implementació a l’entorn Storybook creat pel vostre CI.

Publicació d’una nova versió

Per controlar el nostre cicle de llançament, vam decidir utilitzar la versió semàntica. Per tant, només necessitem afegir "Patch", "Minor" o "Major" al nostre missatge de confirmació de combinació. Això publicarà automàticament una nova versió per al nostre NPM privat. El nostre CI també actualitza el nostre entorn Master Storybook.

Conclusió

La creació d’un kit d’interfície d’usuari no és una tasca fàcil i requereix un gran esforç per part del vostre equip. Tot i això, sens dubte us ajudarà a escalar la vostra sol·licitud i a mantenir-la constant.

Qualsevol actualització important de la interfície d’usuari és fàcil de fer, ja que mantenim els components de la interfície d’usuari aïllats i també és bastant fàcil afegir una nova marca. Tot el que heu de fer és afegir un nou fitxer de disseny.

Un altre avantatge de traslladar la declaració de tema a una biblioteca externa és que a la nostra aplicació principal no li importa gens el tema. En aquest sentit, no té estat, ja que la nostra biblioteca d’interfície d’usuari s’encarrega de tots els nostres temes.

I quan teniu un equip de dissenyadors que utilitzen codi (també conegut com unicorns), poden començar a prototipar aquesta biblioteca. És el prototip de més fidelitat o no?

Si voleu fer servir alguna cosa similar al que fem servir amb Travix, extreuré part de la base de codi i crearé una petita caldera amb Components dissenyats, TypeScript i Jest. Va ser bastant molest configurar-ho tot, així que espero que us agradi: https://github.com/leandrooriente/react-ui-kit-boilerplate.

Gràcies per llegir.