Sådan arkiveres komplekse brugergrænsefladekomponenter i React

Foto af Ash Edmonds på Unsplash

Reaktion er kun 'V'-delen af ​​MVC og vurderes som sådan ikke i, hvordan du arkitekterer dit UI.

Hvis der ikke gives ordentlig opmærksomhed, kan en rimelig stor reaktionsapp hurtigt bukke under for et rod med tilstødende komponenter, hver med et sind af dets egne, og hurtigt krænke den reaktive måde at gøre ting på.

Der er flere nøglepunkter, man skal huske på, mens man bygger med React:

  1. Statsløse komponenter
  2. Sammensætning
  3. Centraliseret statsledelse med Redux

Statsløse komponenter

Dine komponenter skal være så statsløse som muligt; som i, bør dine komponenter ikke køre dets egen tilstand, i stedet afhænge af givet i rekvisitter.

Dette gør dine komponenter forudsigelige og let testbare, da de opfører sig som rene funktioner. Indtast data og spyt JSX ud.

Sammensætning

Dette er en todelt tilgang:

  1. Opdeling af en kompleks komponent i mindre håndterbare bits
  2. Komponering af en kompleks brugergrænseflade fra almindelige brugerdefinerede komponenter

Opdeling af en kompleks komponent i mindre håndterbare bits

Sig, at du har en komponent som denne:

Dette er ikke nøjagtigt klart fra et fugleperspektiv. For mange divaer med klassenavne.

Hvis vi er nødt til at gengive en anden chatboble til måske systembeskeder med en lignende sidefod, kan vi ikke. Is er alt sammen tæt.

Og for at fjerne det hele, er det sådan, vi bruger ovennævnte komponent:

Eventuelle opdateringer til chatboblehovedet, vi er nødt til at rode med hele komponentfilen.

Uden at opdatere vores brug, kan vi blot nedbryde ChatBubble sådan:

Header & Footer kan være i sin egen fil og importeres her. Men et hurtigt kig på ChatBubble, og vi kan se, at ændringen nu gør det meget mere læseligt.

Vi ved, at der er en sidehoved og sidefodsdel til det. Så langt så godt.

Komponering af en kompleks brugergrænseflade fra almindelige brugerdefinerede komponenter

Sig nu, at vi har to slags meddelelser: en, som brugerne sender hinanden som tekst. Andre, der indeholder et galleri med billeder. Alle andre detaljer, som header og sidefod, forbliver de samme.

Med vores nuværende implementering er det betydeligt vanskeligt.

Vi kunne skrive kompleks logik for at forstå, om messageContent inkluderer billeder og opdele dem og udføre alle slags mørk magi for at få det til at fungere.

Eller måske kunne vi gøre noget som dette:

Tjek kropsdelen. Vi gjorde {props.children}. Det betyder, at ethvert barn af komponenten sendes ind her.

Og på opkaldsstedet, gør dette:

Nu kan vi gengive chatbeskeder, som vi finder det passende.

I morgen, når der er en tredje form for chatbesked fra måske en bot, mens sidehoved og sidefod forbliver de samme, opdaterer vi simpelthen, hvordan kropsindholdet gengives fra den komponent, der bruger ChatBubble.

Kode genbrugt :)

Centraliseret statsledelse med Redux

Redux gør vores applikationstilstand forudsigelig ved at holde den på et centralt sted / opbevaringssted.

Den eneste måde at opdatere staten på er at udstede handlinger, der er i formatet:

{
    type: streng,
    nyttelast: Enhver
}

Eksempel:

{
    type: 'SET_USER_DETAILS',
    nyttelast: {
        bruger: {
            _id: 1,
            navn: 'John Doe'
        }
    }
}

Disse handlinger overføres til rene funktioner kaldet reduceringer, der forbruger handlingen og returnerer en ny version af staten. Dette vedholdes derefter i butikken, og alle de funktioner, der abonnerer på den del af statstræet, meddeles.

Eksempel BrugereReducer.js

Disse data kan forbruges af UI på denne måde:

Hver gang butikværdien ændres, modtager brugerkomponenten opdateringer.

Lær om redux fra dette egghead-kursus af Dan Abramov.

Tak for at have læst.

Hit * klap *, hvis du synes, det var værd at være :)

Find mig på linkedin eller vende tilbage til mig i kommentarer.

Ansæt de bedste ReactJs Frontend Developers på Prolanceer.com

Prolanceer.com er en omkostningseffektiv, forudbestemt markedspladsplatform, til at ansætte uafhængige softwarefagfolk på freelance eller kontraktbasis