Kuidas struktureerida oma faile suures React rakenduses - lahendus.

See artikkel järgneb eelmisele pealkirjale Kuidas faile struktureerida suures rakenduses React - probleem. Loodetavasti olete selle kõigepealt läbi lugenud. Selles analüüsisime toimingute / komponentide / konteinerite / reduktoritega alustamise traditsioonilist mudelit ja sellega kaasnevaid probleeme. Selles teises osas pakun välja failide korraldamise viisi, mis:

  1. Lihtsustage koos oleva koodi avastamist
  2. Lihtsustage failide ja komponentide nimetamist
  3. Hõlbustage koodide taaskasutamist ja refaktoriseerimist

Tagasihoidlik ettepanek

Läheme tagasi meie piletimüügi rakendusse ja vaatame, kuidas saaksime seda paremaks muuta. Rohkem kõrgema taseme kaustade asemel hakkame kasutama vähem. Ainult üks päriselt. Mulle meeldib src, kuid selle ühe kausta nimi ei oma tegelikult tähtsust. Ja siis me koondame kõik koos, mis selles kokku kuulub.

Minu jaoks on see Reakti filosoofia algusest peale. Esmalt paigutasime märgistuse (html) ja loogika (JavaScript). Seejärel paigutasime stiilid (css… -in-js). Kuid mingil põhjusel nõudsime meetmete, reduktorite ja muude asjade eraldamist.

Võib-olla on see sellepärast, et lapsekingades polnud Reaktyl täielikku riigihalduslahendust. Ja siis tuli flux, siis redux ja siis veel paljud teised. Ja siis hakkasid inimesed muretsema esitlus- ja konteinerikomponentide tükeldamise pärast. Mis on tõenäoliselt endiselt hea mõte, kuid tõenäoliselt piisab failide jagamisest, pole vaja neid täielikult kaustadesse teisaldada. Nagu kooli sõbrad, keda vihane õpetaja eraldas toa vastaslaudadele.

Meie artistidega seotud koodi väljatöötamine näeb välja järgmine:

Koodiredaktor src-kaustaga, mis sisaldab kaustu Artist, Home, Layout, Search ja Venue. Artist on laiendatud ja sisaldab piltide, lugude, testide, sündmuste, jaluse ja päiste kaustu, samuti toiminguid, konstandid, abistajad, register, päringud ja redigeerija JavaScripti faile.

Kõik on saadaval ühes kaustas, hõlpsasti leitavad. Pole vaja imestada, kas see komponent kasutab reduxit või Apollo klienti GraphQL-i jaoks (sel juhul kasutab see mõlemal veidral põhjusel mõlemat. Hei, ükski kood pole täiuslik!). Lõbus fakt, et ma suutsin sellesse ekraanipilti lisada palju rohkem kasulikke faile, vajades siiski vähem kui täisekraani suurust! Vaatame need ükshaaval üle:

__sokid__

Selles kaustas on tavaliselt üks fail, mis sisaldab vanema kuju. Artisti puhul on kõige tõenäolisem json-objekt, mis tähistab kas API kõne vastust või vähendaja olekut pärast kõnet. Muidugi võib see vajaduse korral sisaldada mitut objekti.

Kaustast __tests__ eraldiseisev põhjus on, et pilkamisi saab kasutada testide jaoks, jah, aga ka lugude jaoks, aga ka muude komponentide testideks ja lugudeks. Mitte ainult Kunstniku oma.

__lood__

Selles kaustas on hulk faile, mis peegeldavad vanema kausta struktuuri, kuid laiendiga .story.js. Nii et /src/Artist/Header/index.js jaoks on olemas vastav src / Artist / __ lugusid __ / Header / index.stories.js. Teise võimalusena võite kõik oma lood panna src / Artist / __ lugusid __ / index.stories.js. Või võite alamkaustadesse panna kausta __loed__, kui see on teie jama.

__ test

See kaust sisaldab kõiki teste ja järgib lugudega sama mustrit, välja arvatud laiendiga .spec.js. See on tõesti fantastiline tunne, kui hakkate lugusid ja kirjeldusi üksteist peegeldama, tarbite samu pilke ja annate meelerahu, et teie kood on kaetud, ning murdub valju häälega, kui see paratamatult refraktori ajal puruneb. Minust palju targemad inimesed on selle poolt välja tulnud ja Jest toetab seda vaikimisi.

toimingud.js, reduktor.js, päringud.js

Need failid on spetsiifilised kahe esimese jaoks redutseerimiseks ja viimase jaoks graafql. Ilma suurema üllatuseta sisaldavad need toiminguid, reduktorit ja päringuid vanema kausta, meie puhul Artisti jaoks.

Nüüd ma tean, et tavaliselt juhtub see siis, kui inimesed hakkavad küsimusi esitama. Näiteks kui teie reduktor asub kaustas Artist, kas see tähendab, et ainult esitaja konteiner saab oma poodi ja toiminguid kasutada? No ei. Absoluutselt mitte. Teil on veel kusagil keskladu, millel on funktsioon combReducer, mis impordib selle reduktori. Asukoht on muutunud, kuid kood töötab endiselt sama. Pole ühtegi konventsiooni, mis nõuaks, et kõik reduktorid peavad olema samas kaustas.

Samuti on kõigil teistel komponentidel lubatud sellest failist toiminguid importida. Muidugi, see loob sõltuvusi domeenide vahel, kuid hei, see on reaalne maailm ja meie üks eesmärke on muuta kood taaskasutamiseks tegelikult lihtsamaks. See ei muuda midagi selle suhtes, kuidas see varem töötas. Seda on lihtsalt lihtsam teada saada.

konstandid.js ja abistajad.js

Need failid pole vähem olulised ja teil on õigus neid ümber nimetada või mitte kasutada. Need on lihtsalt muster, mis jõudis minu viimaste projektide juurde tagasi. Kujutage ette meie rakenduse osa, mis peab käsitlema asukohta: konstandite fail sisaldab selliseid asju nagu ekspordi konstand MI = 'miili'; ekspordikonstants KM = 'kilomeetrit'; mida tuleb mitmes kohas uuesti kasutada. Saate neid hoida oma konteineris või mõnes muus kohas, kuid nende väljavõtmine muudab asjad puhtamaks. Samuti julgustab see olema väärtuste suhtes selgesõnaline, selle asemel, et siin-seal juhuslikke maagilisi numbreid omada.

Samuti on abistajate failil pisikesi funktsioone, mida võidakse uuesti kasutada (või mitte). Näiteks eksport const milesToKm = ({miles}) => miles * 1.60934 ;. Meie rakenduses asuvad mõlemad näited kataloogis / lib-kaustas olemise asemel kataloogis /src/Location/{constants,helpers}.js. Abistajafunktsioonide eraldamisega muudate need ka hõlpsamaks testimiseks.

Siiski on väga oluline kinni pidada peamisest mustrist, mille kohaselt iga fail peab olema domeenikaustas, src-kaustas. Teil on kiusatus kasutada utiliite või lib-kausta, kuid see on viga. Ja selle põhjus on:

Kõik on komponent!

Ma ei saa seda piisavalt rõhutada! Sõna otseses mõttes. Keskmine ei lase mul fonti suuremaks muuta. Kuid tõesti, kõik on komponent. Olen juba paar korda ka sõna domeen kasutanud, kuid DDD on päris asi ja ma ei tea seda asja, aga tean Reacti. Lubage mul öelda seda uuesti:

Kõik on komponent!

Tagasi meie asukohakausta. Võib-olla pole teil tegelikult asukohakonteineri või asukoha esitluskomponenti. Aga see on okei. Teil võib ikka olla kaust Asukoht koos oma konstandite ja abilistega ning selle __tests__ ja kes teab, võib-olla on see ühel päeval konteineris oma kauni kasutajaliidese kuvamiseks. Tõenäoliselt saab see kõigepealt action / reduktoripaari. Kuid igal juhul on see korras. Mõnel kangelasel ei ole keepi ja mõnel komponendil pole kasutajaliidest. Kuid lõpuks on kõik komponent.

index.js, päis, sündmused, jalus

Indeksfail on tõenäoliselt teie konteiner, teised kaustad aga sisaldavad esitluskomponente. Neil ei pea olema oma isiklikku kausta. See nägi lihtsalt minu ekraanipildi jaoks parem ja vähem segane.

Failide ja komponentide nimetamise viis on aga palju olulisem. Pikemalt sellest nüüd.

Failide ja komponentide nimetamine

Pidage meeles, et see on vaid ettepanek. Pole spetsifikatsioon, mitte standard ja selle muutmise korral ei purune midagi. Tegelikult palun tehke sellest oma.

Me kõik teame, et asjade nimetamine on üks kahest arvutiteaduse kõige raskemast väljakutsest koos vahemälu kehtetuks tunnistamisega ja ühe veaga.

Failide ja komponentide nimetamine suures ja kasvavas rakenduses React pole erand. Te oleksite üllatunud, kui palju erinevaid päise komponente väike rakendus võib vajada. Siin on mõned soovitused, kuidas seda lihtsamaks muuta.

Nii intuitiivne kui see ka ei tundu, muudab globaalselt unikaalsete nimede omamine asja tegelikult lihtsamaks. Tegelikult meenutan, et meenutan kedagi Facebookis öeldes, et kõigil nende tuhandetel komponentidel on kordumatud nimed ja neid saab importida ilma selleta kogu tee sisestamata. Samamoodi nõuab ReasonML kordumatuid nimesid ja järelikult ei vaja see isegi importi (pun mõeldud)!

Avatud on koodiredaktor koos kolme reaktorikomponendi JavaScripti failiga: src / Artist / index.js, src / Artist / Events / index.js, src / Artist / Events / List.js

Loodetavasti peaks failinime ja selle komponendi nime vaheline seos olema ilmne. Iga komponent saab oma nime täieliku raja järgi, alustades / src kaustast, kui failinimi on index.js, ja võtab lisaks sellele faili nime, kui seda pole.

  1. /src/Artist/index.js on
  2. /src/Artist/Events/index.js on
  3. /src/Artist/Events/List.js on

Kasutades teed ja failinime ning kuna iga fail või komponent asub kaustas src, muutub nimetamine lihtsamaks ja komponentide globaalsed kordumatud nimed on kastist väljas. See muudab asjad palju sirgjoonelisemaks, kui vaatate rakendust React Dev Tools ja proovite aru saada, milline komponent on milline. Nende nimi on nende täpne asukoht koodbaasis!

Kas see töötab? Kas see skaleerub?

Jah.

Ei, tõsiselt, see töötab. Ma olen seda proovinud! Üksi ; kolmeliikmelises meeskonnas; kuuest või enamast meeskonnast; koos nooremate ja vanemate arendajatega. Ma ei taha kunagi tagasi minna. Eriti näiteks rekvisiitide renderdamise, Apollo päringukomponendi ja eelseisva React Suspense API-ga, kus… kõik on komponent. Kas ma pean seda uuesti ütlema?

See failistruktuur:

  1. Muudab koos oleva koodi hõlpsamaks avastamiseks
  2. Lihtsustab failide ja komponentide nimetamist
  3. Hõlbustab komponentide korduvkasutamist ja uuesti reageerimist

See on kõik!

Palun meeldida ja tellida. Kuid veelgi tähtsam - andke mulle teada, kas olete seda proovinud, meeldinud või mitte või kui teil on mõni muu teie jaoks sobiv failistruktuur. Olen üsna kindel, et olen näinud vabas looduses projekte sama asja tegemas. Tõenäoliselt on see sarnane redux-partide mustriga (ehkki tegelikult pole redux-i spetsiifiline). Ja kindlasti pole ma midagi uut ega murrangulist seal leiutanud. Kuid olen alati üllatunud traditsiooniliste toimingute / komponentide / konteinerite / reduktorite ülesehituse leidmise üle ja soovisin tulevikus midagi millele osutada. Andke mulle ka teada, kui olete leidnud sarnase idee, mida väljendatakse vähem sõnades.

Suur tänu Julienile ja Guillaume'ile, kes lugesid selle postituse mustandeid ja aitasid mul seda parandada.