Sådan bygger du et skalerbart React UI Kit

Foto af Blake Wheeler

Hos Travix har vi et enkelt produkt med 4 forskellige temaer. Hvert tema er et uafhængigt brand, og hvert brand har nogle websteder. I øjeblikket har vi mere end 45 websteder, der kører på vores platform.

To af vores 4 forskellige mærker

For at holde alt fungerer, har vi noget tæt på 40 frontend-udviklere, der arbejder på produktet, og det er ret svært at holde kodebasen og design ensartet.

Hvis du arbejder i et stort React-projekt, har du sandsynligvis en slags UI-kit integreret i din codebase. Den fælles knapkomponent, en Modal generisk implementering, en kalender, som du bruger hele tiden, fælles komponenter, der ikke indeholder nogen forretningslogik.

Hovedmålet med denne artikel er at hjælpe dig med at udvikle og organisere dit UI Kit, så du kan forbedre din udviklingsproces og designkonsistensen af ​​dit projekt.

Som du kan forestille dig, afhænger dette bibliotek ikke kun af dit udviklingshold. Du skal også involvere designerne. Det betyder ikke noget, hvor dygtig du er, eller hvilke teknologier du vælger, hvis dit designteam beder om 9 forskellige knapper og 22 skriftstørrelser.

Hvis du er heldig, vil dette ikke være et stort problem. Det bliver ret almindeligt i designteam at have en stilguide. Men hvis held ikke er din bedste dygtighed, kan du have noget som gråCantBeLighterThan Dette variabelnavn i dit tema (sand historie).

Teknologi

Som titlen siger, bruger vi React til at opbygge vores applikation. De fleste af tipene i denne artikel kan let bruges i forskellige arkitekturer, da de har lignende værktøjer og biblioteker.

Storybook

Storybook vil være din udviklingslegeplads og komponentgalleri. Det hjælper med at tænke i din komponent som en isoleret pakke og adskille dem til dit produkt, så du kan have generiske og velbeskrevne egenskaber.

Ikke genanvendelig komponent

En specifik implementering af en knap

Generisk komponent

Generel implementering af en knap

Storybook er også god til at levere dokumentation. Der er en addon kaldet storybook-addon-info, som automatisk tilføjer komponenten JSX og prop-typebeskrivelsen til komponentsiden.

At køre hele applikationen kræver sandsynligvis få trin og kan være virkelig langsom. Storybook er normalt hurtigere at starte, så det forbedrer din udviklingshastighed. Du kan udvikle dine UI-komponenter, der håner alle egenskaber (storybook-addon-knotter er perfekte til hån) på en fuldstændig isoleret legeplads uden at køre dit hovedprogram.

Stylede komponenter

Du har også brug for noget at beskæftige sig med tema. Vi prøvede rene CSS-variabler før, og det fungerede godt. Dit bundt har to CSS-filer, en med bibliotekskomponenten og en anden til variabeldeklaration. Hvis du har mere end et tema, skal du bare skifte temafil, og det skal fungere.

Dem ved hjælp af ren CSS

I vores nye bibliotek besluttede vi at gå med Styled Components. Det giver allerede en temaløsning, og CSS i JS fungerer temmelig godt med React. Du har også scoped CSS som standard, der løser det største problem inden for datalogi, navngivning.

Dette er en fantastisk måde at undgå enhver uventet CSS-tilsidesættelse og forhindrer også, at udviklere med vilje tilsidesætter CSS-regler. Din komponentadfærd er koblet knyttet til sin egen egenskapsdefinition, og ingen kan globalt tilsidesætte stilarter.

Det hjælper dig også med bedre at definere betingede regler i dine stilarter, fordi du ikke behøver at udvide CSS-klasser eller at administrere dem i dit element. Du videregiver dybest set rekvisitter til en visningskomponent, og denne komponent kan bruge den til at håndtere kantsager.

Valgt tema tilgængeligt til brug i vores komponenter

Hos Travix oprettede vi en Storybook-tilføjelse til let at ændre vores tema. Hvis du har spillet med Styled Components ThemeProvider, ved du, at vi dybest set skal ændre temaegenskaben, og det fungerer som en charme. Denne tilføjelse hjælper os med at teste alle mærker under udvikling og hjælper også produkteiere (PO'er) og designere med at validere implementeringen.

Temavælger tilføjelse

maskinskrift

Vi havde få problemer med at implementere TypeScript. Vi brugte mindst to uger på at opdatere vores løsning for at understøtte den og mere to uger på at migrere alt. Hvis du beslutter at bruge det, vil jeg varmt anbefale at starte dit projekt med TypeScript fra bunden.

Men det lønner sig bestemt, og automatisk færdiggørelse af egenskaber og værdier hjælper meget under udviklingen. Det hjælper dig også med at definere bedre kontrakter til din komponent, da enhver definition af eksotisk ejendomstype tændes med rødt lys under gennemgangsprocessen.

TypeScript autocomplete

Eslint

For at sikre konsistensen af ​​codebase har vi en superstreng eslint-konfiguration. Vi besluttede at gå fuldt ud her, så vi ikke spilder tid på at gennemgå mindre detaljer i koden.

Vores linter kører automatisk inden ethvert skub, hvor en auto-fix ændres til det sidste engagement. Den kører også i vores CI-maskine, så hvis nogen beslutter at springe valideringen over, vil den mislykkes under opbygningen.

Udviklingsproces

Den vigtigste del for os vedrørte ikke selve teknologien, men processen. Vi brugte meget tid på at forsøge at holde det så strengt som muligt, så vi kan garantere bibliotekets kvalitet på lang sigt. Dette er ganske vigtigt i en stor virksomhed, fordi udviklere forlader, udviklere tilslutter sig, men din codebase vil være tidens prøve.

RFC-anmodning om træk

RFC betyder "anmodning om kommentarer". I denne pull-anmodning implementerer vi ikke en enkelt kodelinje. Vi tilføjer dybest set en markdown-fil, der beskriver vores komponent. Brug sager, egenskaber, tilbagekald, mulige bivirkninger.

Dit nye bibliotek bliver brugt af hele virksomheden og vil have en masse kantsager og mindre detaljer at justere. Trækforespørgsler kan let blive store tråde til at diskutere, om komponenten skal være en HOC eller renderProps, noget mere komposibelt eller mere strengt, kontrolleret eller ukontrolleret, og så videre. Så RFC hjælper dig med ikke at spilde tid på at implementere noget, der vil blive fuldstændigt ændret efter gennemgangen.

Gennemgang af anmodning om anmodning

Vores gennemgang af pull-anmodning kræver få automatiserede trin, tre godkendere af udviklere og PO / Designers-anmeldelser. Intet er fusioneret, hvis et af disse trin mislykkes.

CI-trin:
- Kør eslint og test.
- Kontroller, om kodedækningen ikke mindskes.
- Opret et unikt historiebogsmiljø (det opdaterer også miljøet, hvis du begår noget nyt).

Udviklerne, der gennemgår din pull-anmodning, skal kun kontrollere, om implementeringen matcher den RFC, der allerede er godkendt, og om designet er korrekt.

Designere og PO'er kan gennemgå din implementering ved hjælp af storybook-miljøet oprettet af dit CI.

Slip en ny version

For at kontrollere vores udgivelsescyklus besluttede vi at bruge Semantic Release, så vi er bare nødt til at tilføje “patch”, “minor” eller “major” i vores merge commit-meddelelse, og det frigiver automatisk en ny version til vores private NPM. Vores CI opdaterer også vores master storybook-miljø.

Konklusion

At opbygge et UI-kit er ikke en nem opgave og kræver en masse indsats fra dit team, men det vil bestemt hjælpe dig med at skalere din ansøgning og at holde den konsekvent.

Enhver større UI-opdatering opnås let, da vi holder vores UI-komponenter isoleret, og det er også ganske nemt at tilføje ethvert nyt brand, vi skal bare tilføje en ny temafil.

En anden fordel ved at flytte vores temadeklaration til et eksternt bibliotek er, at vores hovedapplikation overhovedet ikke er interesseret i tema. Det er statsløst i den forstand, fordi vores UI-bibliotek tager sig af alle vores temaer.

Og hvis du har et team af designere, der koder (også kaldet Unicorns), kan de begynde at prototype ved hjælp af dette bibliotek. Er det den mest høje tro-prototype eller ej?

Hvis du vil bruge noget, der ligner det, vi bruger på Travix, udtrækker jeg en del af kodebasen og skabte en lille kedelplade med Stylede komponenter, TypeScript og Jest. Det var ret irriterende at konfigurere alt, så jeg håber du kan lide det: https://github.com/leandrooriente/react-ui-kit-boilerplate.

Tak for at have læst.