Presentasjons-Og Containerkomponenter

Oppdatering fra 2019: jeg skrev denne artikkelen for lenge siden, og mine synspunkter har siden utviklet seg. Spesielt foreslår jeg ikke å dele komponentene dine som dette lenger. Hvis du finner det naturlig i kodebasen, kan dette mønsteret være nyttig. Men jeg har sett det håndheves uten nødvendighet og med nesten dogmatisk glød altfor mange ganger. Den viktigste grunnen til at jeg fant det nyttig var fordi det la meg skille kompleks stateful logikk fra andre aspekter av komponenten. Kroker la meg gjøre det samme uten en vilkårlig divisjon. Denne teksten er intakt av historiske grunner, men ikke ta det for alvor.

Det er et enkelt mønster jeg finner utrolig nyttig når jeg skriver React-applikasjoner. Hvis Du Har reagert En stund, har du sannsynligvis allerede oppdaget det. Denne artikkelen forklarer det bra, men jeg vil legge til noen flere poeng.

du finner komponentene dine mye lettere å gjenbruke og begrunne om du deler dem i to kategorier. Jeg kaller Dem Container og Presentasjonskomponenter* men jeg hørte Også Fett og Tynn, Smart og Dum, Stateful og Ren, Skjermer og Komponenter, etc. Disse alle er ikke akkurat det samme, men kjernen ideen er lik.

mine presentasjonskomponenter:

• er opptatt av hvordan ting ser ut.
• kan inneholde både presentasjons-og containerkomponenter** inne, og har vanligvis NOEN DOM-markeringer og stiler av sine egne.
• tillater ofte inneslutning via dette.rekvisitter.barn.
• Har ingen avhengigheter på resten av appen, for Eksempel Flux handlinger eller butikker.
• ikke angi hvordan dataene lastes eller muteres.
• Motta data og tilbakeringinger utelukkende via rekvisitter.
• Har Sjelden sin egen tilstand (når de gjør DET, ER DET UI-tilstand i stedet for data).
• skrives som funksjonelle komponenter med mindre de trenger state, livssykluskroker eller ytelsesoptimaliseringer.
• Eksempler: Side, Sidebar, Historie, UserInfo, Liste.

mine beholderkomponenter:

• er opptatt av hvordan ting fungerer.
• kan inneholde både presentasjons-og containerkomponenter * * inne, men har vanligvis ikke NOEN DOM-markering av seg selv, bortsett fra noen innpakningsdivs, og har aldri noen stiler.
• Gi dataene og virkemåten til presentasjonelle eller andre beholderkomponenter.
• Ring Flux-handlinger og gi disse som tilbakeringinger til presentasjonskomponentene.
• er ofte stateful, som de pleier å tjene som datakilder.
• genereres vanligvis ved hjelp av høyere ordens komponenter som connect () Fra React Redux, createContainer () Fra Relay eller Container.lag() Fra Flux Utils, i stedet for skrevet for hand.
• Eksempler: UserPage, FollowersSidebar, StoryContainer, FollowedUserList.

jeg legger dem i forskjellige mapper for å gjøre dette skillet klart.

Fordeler Med Denne Tilnærmingen

• Bedre separasjon av bekymringer. Du forstår din app og UI bedre ved å skrive komponenter på denne måten.
• Bedre gjenbrukbarhet. Du kan bruke samme presentasjonskomponent med helt forskjellige statskilder, og slå dem til separate beholderkomponenter som kan gjenbrukes ytterligere.
• Presentasjonskomponenter er i hovedsak appens “palett”. Du kan sette dem på en enkelt side og la designeren justere alle sine variasjoner uten å berøre appens logikk. Du kan kjøre screenshot regresjon tester på den siden.
• dette tvinger deg til å trekke ut “layoutkomponenter” som Sidebar, Side, ContextMenu og bruke dette.rekvisitter.barn i stedet for å duplisere samme markering og layout i flere containerkomponenter.

Husk at komponenter ikke trenger Å sende DOM. De trenger bare å gi sammensetningsgrenser mellom UI-bekymringer.

Dra nytte av det.

når Skal Man Introdusere Beholdere?

jeg foreslår at du begynner å bygge appen din med bare presentasjonskomponenter først. Til slutt vil du innse at du passerer for mange rekvisitter ned mellomkomponentene. Når du oppdager at noen komponenter ikke bruker rekvisitter de mottar, men bare videresender dem, og du må rewire alle de mellomliggende komponentene når barna trenger mer data, er det en god tid å introdusere noen containerkomponenter. På denne måten kan du få data og atferd rekvisitter til blad komponenter uten å belaste urelaterte komponenter i midten av treet.

Dette er en pågående prosess med refactoring, så prøv ikke å få det riktig første gang. Som du eksperimentere med denne syklusen, vil du utvikle en intuitiv følelse for når det er på tide å trekke ut noen flasker, akkurat som du vet når det er på tide å trekke ut en funksjon. Min Gratis Redux Egghead serien kan hjelpe deg med det også!

Andre Dikotomier

det er viktig at du forstår at skillet mellom presentasjonskomponentene og beholderne ikke er teknisk. Snarere er det et skille i deres formål.

Derimot er her noen relaterte (men forskjellige!) tekniske forskjeller:

• Statsløs og Statsløs. Noen komponenter bruker React setState () – metoden, og noen gjør det ikke. mens containerkomponenter har en tendens til å være statelige og presentasjonskomponenter har en tendens til å være statsløse, er dette ikke en vanskelig regel. Presentasjonelle komponenter kan være stateful, og beholdere kan også være statsløse.
• Klasser Og Funksjoner. Siden React 0.14, kan komponenter deklareres både som klasser og som funksjoner. Funksjonelle komponenter er enklere å definere, men de mangler visse funksjoner som for øyeblikket bare er tilgjengelige for klassekomponenter. Noen av disse restriksjonene kan gå bort i fremtiden, men de eksisterer i dag. Fordi funksjonelle komponenter er enklere å forstå, foreslår jeg at du bruker dem med mindre du trenger stat, livssykluskroker eller ytelsesoptimaliseringer, som bare er tilgjengelige for klassekomponentene for øyeblikket.
• Rent Og Urent. Folk sier at en komponent er ren hvis det er garantert å returnere samme resultat gitt samme rekvisitter og tilstand. Rene komponenter kan defineres både som klasser og funksjoner, og kan være både statsløse og statsløse. Et annet viktig aspekt ved rene komponenter er at de ikke stole på dype mutasjoner i rekvisitter eller tilstand, slik at deres gjengivelsesytelse kan optimaliseres ved en grunne sammenligning i deres shouldComponentUpdate () krok. Foreløpig kan bare klasser definere shouldComponentUpdate (), men det kan endres i fremtiden.

både presentasjonskomponenter og beholdere kan falle inn i en av disse skuffene. I min erfaring har presentasjonskomponenter en tendens til å være statsløse rene funksjoner, og beholdere har en tendens til å være statlige rene klasser. Men dette er ikke en regel, men en observasjon, og jeg har sett de motsatte tilfellene som var fornuftige under bestemte omstendigheter.

ikke ta presentasjons-og containerkomponent-separasjonen som et dogme. Noen ganger spiller det ingen rolle, eller det er vanskelig å tegne linjen. Hvis du føler deg usikker på om en bestemt komponent skal være presentasjonell eller en beholder, kan det være for tidlig å bestemme seg. Ikke svett det!

Eksempel

Dette gist Av Michael Chan ganske mye negler det.

Videre Lesing

• Komme I Gang Med Redux
• Mixins Er Døde, Lenge Leve Komposisjon
• Container Komponenter
• Atomic Web Design
• Bygge Facebook News Feed Med Relay

Fotnoter

* I en tidligere versjon av denne artikkelen kalte jeg dem” smarte “og” dumme ” komponenter, men dette var altfor hardt for presentasjonskomponentene, og viktigst, forklarte egentlig ikke forskjellen i deres formål. Jeg liker de nye vilkårene mye bedre, og jeg håper at du gjør det også!

* * i en tidligere versjon av denne artikkelen hevdet jeg at presentasjonskomponenter bare skal inneholde andre presentasjonskomponenter. Jeg tror ikke lenger dette er tilfelle. Om en komponent er en presentasjonskomponent eller en beholder, er implementeringsdetaljene. Du bør kunne erstatte en presentasjonskomponent med en beholder uten å endre noen av anropsområdene. Derfor kan både presentasjons-og containerkomponenter inneholde andre presentasjons-eller containerkomponenter helt fint.