Jauna pieeja reaktīvo komponentu projektēšanai

2015. gadā Dens Abramovs uzrakstīja rakstu Presentational and Container Components, kuru daži React jaunpienācēji nepareizi interpretēja kā baušļus. Patiesībā es pats paklupu pie raksta un daudziem citiem, kas atkārto tā mācību, un es domāju, ka tam ir jābūt labākajam veidam, kā nošķirt bažas starp sastāvdaļām .

Bet pats Dens Abramovs vēlāk uzrunāja sabiedrību, lai tā turētos pie viņa izklāstītajiem dizaina modeļiem.

Strādājot ar React jau vairāk nekā gadu, esmu paklupis savos dizaina modeļos un šeit mēģināšu tos formalizēt. Izmantojiet šīs idejas ar sāls graudiņu, tās ir tikai manis pašas novērotas lietas, kuras man šķita konstruktīvas.

Izbēgšana no divkosības

Ilgu laiku komponenti tiek plaši klasificēti kā gudri vai mēms, konteineri vai prezentācijas, valstiski vai bezvalstnieki, tīri vai netīri. Terminoloģijas ir daudz, taču tās visas nozīmē apmēram to pašu. Viedie komponenti zina, kā sasiet jūsu lietojumprogrammu, un mēms komponenti vienkārši uzņem datus, lai tos iesniegtu galalietotājam. Šī ir noderīga atšķirība, bet tā patiešām nav tā, kā es uzskatu, ka es domāju, izstrādājot komponentus.

Container vs Presentational domāšanas problēma ir tā, ka tā pārāk grūti cenšas definēt komponentu atbildību stāvokļa, loģikas un citu komponenta iekšējās darbības aspektu ziņā.

Komponentu dizains ir labāk pieejams, atliekot ieviešanas detaļas un domājot par komponentu saskarnēm . Īpaši svarīgi ir padomāt par to, kāda veida pielāgošanai vajadzētu atļaut komponentu un kādas netiešas un skaidras atkarības komponentam jāietver.

Iepazīstinām ar trihotomiju

Trihotomija? Vai tas ir pat vārds? Es nezinu, bet jums ir ideja. Esmu iedomājies, ka React komponenti ietilpst vienā no trim atkritumu tvertnēm.

Universālās sastāvdaļas

Tie ir komponenti, kurus var izmantot daudzas reizes jebkurā lietojumprogrammā .

Šie komponenti:

  • Vajadzētu izmantot atkārtoti
  • Tam jābūt ļoti pielāgojamam
  • Jums nevajadzētu zināt par lietojumprogrammas kodu, ieskaitot modeļus, veikalus, pakalpojumus utt.
  • Vajadzētu samazināt atkarību no trešo pušu bibliotēkām
  • Tas reti jāizmanto tieši jūsu lietojumprogrammā
  • Būtu jāizmanto kā globālo komponentu pamatelementi
  • Var beigties ar sufiksu “Base” (piem., ButtonBase, ImageBase)

Tie ir pamatkomponenti, kas ir lietojumprogrammas agnostiski un nav obligāti jāizmanto tieši jūsu skata komponentos, jo tie bieži ir pārāk pielāgojami. Lai tos tieši izmantotu View komponentos, tas nozīmētu daudz kopēt un ielīmēt vienu katla plāksni. Jūs arī riskējat, ka izstrādātāji ļaunprātīgi izmanto komponentu ļoti pielāgojamo raksturu veidos, kas rada pretrunīgu pieredzi visā jūsu lietojumprogrammā.

Globālie komponenti

Tie ir komponenti, kurus vienā lietojumā var izmantot daudzas reizes .

Šie komponenti:

  • Vajadzētu izmantot atkārtoti
  • Tam jābūt minimāli pielāgojamam
  • Var izmantot lietojumprogrammas kodu
  • Būtu jāievieš universālie komponenti , ierobežojot to pielāgošanu
  • Būtu jāizmanto kā komponentu View komponentiem
  • Bieži sasaistiet viens pret vienu ar modeļa gadījumiem (piemēram, DogListItem, CatCard)

Šie komponenti ir atkārtoti izmantojami jūsu lietojumprogrammā, taču tos nevar viegli pārsūtīt uz citām lietojumprogrammām, jo ​​tie ir atkarīgi no lietojumprogrammas loģikas. Tie ir komponentu View komponentiem un citiem globālajiem komponentiem.

Tiem jābūt minimāli pielāgojamiem, lai nodrošinātu konsekvenci visā jūsu lietojumprogrammā. Lietojumprogrammās nedrīkst būt trīsdesmit dažādas pogu variācijas, drīzāk tām jābūt nedaudzām dažādu pogu variācijām. Tas būtu jāīsteno, ņemot ļoti pielāgojamu Universal ButtonBase komponentu un tajā iekļaujot stilus un funkcionalitāti globālās pogas komponenta veidā. Globālie komponenti bieži izpaužas citā formā kā domēna modeļa datu attēlojums.

Skatīt komponentus

Tie ir komponenti, kas jūsu lietojumprogrammā tiek izmantoti tikai vienu reizi .

Šie komponenti:

  • Ja nav iespējams bažas par otrreizēju
  • Visticamāk pārvaldīs valsti
  • Saņemiet minimālu rekvizītu
  • Vajadzētu sasaistīt kopā globālos komponentus (un, iespējams, universālos komponentus)
  • Bieži atrisina lietojumprogrammu maršrutus
  • Bieži uzturiet īpašu skatu nekustamā īpašuma gabalu
  • Bieži vien ir liels atkarību skaits
  • Vajadzētu būt jūsu pieteikuma pamatelementiem

Šie ir jūsu lietojumprogrammas augstākā līmeņa komponenti, kas salīmē atkārtoti izmantojamus komponentus un pat citus skatus. Bieži vien tie ir komponenti, kas atrisina maršrutus un var tikt parādīti lapas līmeņa komponentu veidā. Tās ir smagas stāvoklī un vieglas butaforijās. Tas ir tas, ko Dans Abramovs uzskatītu par konteineru sastāvdaļām.

PromiseButton

Apskatīsim solījuma pogas universālo un globālo ieviešanu un redzēsim, kā tās salīdzina. Solījuma poga darbojas kā parasta poga, ja vien onClick apdarinātājs neatdod solījumu. Atdota solījuma gadījumā poga var nosacīti atveidot saturu, pamatojoties uz solījuma stāvokli.

Ievērojiet, kā PromiseButtonBase ļauj mums kontrolēt to, ko renderēt jebkurā solījuma dzīves cikla brīdī, bet PromiseButton cepeškrāsnī PulseLoader tiek gatavots gaidīšanas stāvoklī. Jebkurā laikā, kad izmantojam PromiseButton, mums tiek garantēta zilganiekrāvēja animācijas animācija, un mums nav jāuztraucas par šī koda dublēšanu vai pretrunīgas iekraušanas pieredzes nodrošināšanu, mūsu lietojumprogrammā iekļaujot vairākas vairāku krāsu ielādes animācijas. PromiseButtonBase ir pielāgojams, bet PromiseButton ir ierobežojošs.

Direktorija struktūra

Turpmāk parādīts, kā mēs varētu organizēt komponentus pēc šī modeļa.

App/ App.js Views/ DogListView/ Global/ Models/ Dog/ DogListItem/ Image/ PromiseButton/ Universal/ ImageBase/ PromiseButtonBase/

Komponentu atkarības

Zemāk parādīts, kā iepriekš minētie komponenti ir atkarīgi viens no otra.

/* App.js */ import { DogListView } from './Views' /* DogListView.js */ import { DogListItem } from 'App/Global/Models/Dog' /* DogListItem.js */ import Image from '../../Image', import PromiseButton from '../../PromiseButton' /* Image.js */ import { ImageBase } from 'Universal' /* PromiseButton.js */ import { PromiseButtonBase } from 'Universal'

Mūsu skata komponents ir atkarīgs no globālā komponenta, un mūsu globālais komponents ir atkarīgs no citiem globālajiem komponentiem, kā arī no universālajiem komponentiem. Šī atkarības plūsma būs diezgan izplatīta. Ievērojiet arī absolūtā un relatīvā importa izmantošanu. Ir patīkami izmantot relatīvo importu, piesaistot atkarības, kas atrodas tajā pašā modulī. Turklāt ir patīkami izmantot absolūtu importēšanu, ieviešot atkarības starp moduļiem vai kad direktoriju struktūra ir dziļi ligzdota vai bieži mainās.

Konteinera un prezentācijas modeļa problēma ir tā, ka tas pārāk cenšas definēt komponentu atbildību komponentu iekšējās darbības ziņā. Galvenais līdzņemšanas veids ir komponentu dizaina skatīšana komponentu saskarņu izteiksmē . Mazāk svarīga ir ieviešana, kas ļauj komponentam izpildīt savu līgumu. Ir svarīgi domāt par to, kāda veida pielāgošanai vajadzētu atļaut komponentu un kādas netiešas un skaidras atkarības komponentam jāietver.

Ja jums šīs domas ir noderīgas un vēlaties redzēt vairāk manu ideju, droši pārbaudiet šo repo, kuru izmantoju, lai saglabātu savas domas un labāko praksi React / Redux lietotņu rakstīšanai.