presentaatio-ja Pakkauskomponentit

päivitys 2019: kirjoitin tämän artikkelin kauan sitten ja näkemykseni ovat sittemmin kehittyneet. En suosittele enää osien jakamista näin. Jos pidät sitä luonnollisena codebase, Tämä kuvio voi olla kätevä. Mutta olen nähnyt sen toteutuvan ilman tarvetta ja lähes dogmaattisella kiihkolla aivan liian monta kertaa. Tärkein syy löysin sen hyödylliseksi oli, koska se salli minun erottaa monimutkainen stateful logiikka muista osa. Hooks antaa minun tehdä saman asian ilman mielivaltaista jakoa. Tämä teksti on jätetty koskemattomaksi historiallisista syistä, mutta älä ota sitä liian vakavasti.

on yksinkertainen kuvio, josta on mielestäni valtavasti hyötyä React-hakemuksia kirjoitettaessa. Jos olet tehnyt reagoida jonkin aikaa, olet luultavasti jo löytänyt sen. Tämä artikkeli selittää sen hyvin, mutta haluan lisätä vielä muutaman seikan.

huomaat, että komponenttisi on paljon helpompi käyttää uudelleen ja järkeillä, jos jaat ne kahteen luokkaan. Kutsun niitä kontti ja Presentational komponentit* mutta kuulin myös rasvaa ja laiha, fiksu ja tyhmä, Stateful ja puhdas, näytöt ja komponentit, jne. Nämä kaikki eivät ole aivan samanlaisia, mutta ydinajatus on samanlainen.

esiosani:

• ovat huolissaan siitä, miltä asiat näyttävät.
• voi sisältää sekä presentaatio-että konttorikomponentteja* * sisällä, ja niissä on yleensä omat DOM-merkkinsä ja tyylinsä.
• mahdollistavat usein eristämisen tämän kautta.rekvisiitta.lapsi.
• ei ole riippuvuuksia muusta sovelluksesta, kuten Flux-toiminnoista tai varastoista.
• ei täsmennetä, miten tiedot ladataan tai muunnetaan.
• vastaanottaa tietoja ja soittoja yksinomaan rekvisiitan kautta.
• harvoin on omaa tilaa (kun ne tekevät, se on UI-tila datan sijaan).
• on kirjoitettu toiminnallisiksi osiksi, elleivät ne tarvitse tilaa, elinkaarikoukkuja tai suorituskyvyn optimointia.
• Esimerkkejä: Sivu, Sivupalkki, Tarina, UserInfo, Lista.

omat pakkauskomponentit:

• ovat huolissaan siitä, miten asiat toimivat.
• voi sisältää sekä presentaatio-että pakkauskomponentteja** sisällä, mutta niissä ei yleensä ole omia Dom-markupeja lukuun ottamatta joitain kääre-divejä, eikä niissä ole koskaan mitään tyyliä.
• anna tiedot ja käyttäytyminen presentaatiokomponenteille tai muille kontin komponenteille.
• Soita Flux-toimintoja ja tarjoa ne perehdytyskomponenttien takaisinkutsuina.
• ovat usein statatiivisia, sillä ne toimivat yleensä tietolähteinä.
• tuotetaan yleensä korkeamman kertaluvun komponenteilla, kuten connect() React Reduxista, createContainer() releestä tai säiliöstä.luo () Flux Utilsista käsin kirjoitetun sijaan.
• Esimerkkejä: UserPage, Followersidebar, StoryContainer, Followed Userlist.

laitoin ne eri kansioihin, jotta tämä ero olisi selvä.

tämän lähestymistavan hyödyt

• huolien parempi erottaminen toisistaan. Ymmärrät sovelluksesi ja käyttöliittymäsi paremmin kirjoittamalla komponentteja tällä tavalla.
• parempi uudelleenkäytettävyys. Voit käyttää samaa presentational komponentti täysin eri valtion lähteistä, ja muuttaa ne erillisiksi säiliökomponentit, jotka voidaan edelleen käyttää uudelleen.
• Esityskomponentit ovat oleellisesti sovelluksesi “paletti”. Voit laittaa ne yhdelle sivulle ja antaa suunnittelijan nipistää kaikki niiden muunnelmat koskematta sovelluksen logiikkaan. Voit suorittaa kuvakaappaus regressiotestejä kyseisellä sivulla.
• tämä pakottaa poimimaan “asettelukomponentteja”, kuten sivupalkin, sivun, asiayhteyden ja käyttämään tätä.rekvisiitta.lapset sen sijaan, että kopioidaan sama markup ja layout useita kontti osia.

muista, että komponenttien ei tarvitse emittoida Domia. Niiden on vain annettava KOOSTUMUSRAJOJA unionin tuotannonalan huolenaiheiden välillä.

hyödynnä sitä.

milloin Kontit otetaan käyttöön?

ehdotan, että alat rakentaa sovellustasi ensin pelkistä esillepanevista komponenteista. Lopulta huomaat, että siirrät liikaa rekvisiittaa alas väliosia. Kun huomaat, että jotkut komponentit eivät käytä vastaanottamaansa rekvisiittaa, vaan vain välittävät ne eteenpäin ja sinun on johdettava kaikki ne välikomponentit uudelleen aina, kun lapset tarvitsevat lisää tietoa, on hyvä aika ottaa käyttöön joitakin säiliökomponentteja. Näin saat tiedot ja käyttäytymisen rekvisiitta lehtien komponentteja rasittamatta toisiinsa liittyvät osat keskellä puuta.

tämä on jatkuva refaktorointiprosessi, joten älä yritä saada sitä oikein ensimmäisellä kerralla. Kun kokeilet tätä mallia, kehität intuitiivisen tunteen, kun on aika purkaa joitakin säiliöitä, aivan kuten tiedät, milloin on aika purkaa toiminto. Minun ilmainen Redux Egghead sarja voi auttaa sinua, että liian!

muut Dikotomiat

on tärkeää, että ymmärrät, että esityskomponenttien ja säiliöiden välinen ero ei ole tekninen. Se on pikemminkin ero niiden tarkoituksessa.

sen sijaan tässä on muutamia toisiinsa liittyviä (mutta erilaisia!) tekniset erot:

• valtiollinen ja valtioton. Jotkut komponentit käyttävät React setState () – menetelmää ja jotkut eivät. vaikka säiliökomponentit ovat yleensä tilallisia ja edustukselliset komponentit ovat yleensä tilattomia, tämä ei ole kova sääntö. Presentational komponentit voivat olla stateful, ja säiliöt voivat olla stateless liian.
• luokat ja tehtävät. Koska React 0,14, komponentit voidaan julistaa sekä luokiksi että funktioiksi. Toiminnalliset komponentit ovat yksinkertaisempia määritellä, mutta niistä puuttuu tiettyjä ominaisuuksia, jotka ovat tällä hetkellä saatavilla vain luokkakomponenteille. Jotkin näistä rajoituksista saattavat poistua tulevaisuudessa, mutta ne ovat olemassa tänään. Koska toiminnalliset komponentit ovat helpommin ymmärrettäviä, ehdotan, että käytät niitä, ellet tarvitse tila -, elinkaarikoukkuja tai suorituskyvyn optimointeja, jotka ovat tällä hetkellä saatavilla vain luokan komponenteille.
• puhdas ja epäpuhdas. Ihmiset sanovat, että komponentti on puhdas, jos se on taattu palauttaa saman tuloksen annetaan sama rekvisiitta ja valtion. Puhtaat komponentit voidaan määritellä sekä luokiksi että funktioiksi, ja ne voivat olla sekä tilallisia että tilattomia. Toinen tärkeä piirre puhtaissa komponenteissa on, että ne eivät luota syviin mutaatioihin rekvisiitassa tai tilassa, joten niiden renderöintisuoritus voidaan optimoida matalalla vertailulla niiden shouldComponentUpdate () – koukkuun. Tällä hetkellä vain luokat voivat määritellä shouldComponentUpdate (), mutta se voi muuttua tulevaisuudessa.

sekä esillepanokomponentit että astiat voivat pudota kumpaan tahansa näistä ämpäreistä. Kokemukseni mukaan presentaatiokomponentit ovat yleensä stateless pure-funktioita, ja kontit ovat yleensä stateful pure-luokkia. Tämä ei kuitenkaan ole sääntö vaan havainto, ja olen nähnyt täysin päinvastaisia tapauksia, joissa oli järkeä tietyissä olosuhteissa.

älä ota presentaatiokomponentin ja kontin erottelua dogmiksi. Joskus sillä ei ole väliä tai rajan vetäminen on vaikeaa. Jos sinusta tuntuu epävarma siitä, onko tietyn komponentin pitäisi olla presentational tai säiliö, se voi olla liian aikaista päättää. Älä hermoile!

Example

this gist by Michael Chan pretty much nails it.

Further Reading

• Getting Started with Redux
• Mixins are Dead, Long Live Composition
• Container Components
• Atomic Web Design
• Building the Facebook News Feed with Relay

alaviitteet

* aiemmassa versiossa tämän artikkelin kutsuin niitä “smart” ja “tyhmä” komponentit, mutta tämä oli liian ankara edustuksellisia komponentteja ja, mikä tärkeintä, ei oikeastaan selittää eroa niiden tarkoitus. Nautin uusista ehdoista paljon enemmän, ja toivon, että tekin!

* * tämän artikkelin aiemmassa versiossa väitin, että esityskomponenttien tulisi sisältää vain muita esityskomponentteja. En enää usko, että näin on. Riippumatta siitä, onko komponentti esityskomponentti vai säiliö, on sen täytäntöönpanoa koskeva yksityiskohta. Sinun pitäisi pystyä korvaamaan presentational komponentti säiliö muuttamatta mitään puhelun sivustoja. Siksi sekä presentational ja säiliökomponentit voivat sisältää muita presentational tai säiliökomponentteja hienosti.