Laste-vanemate suhtlus jalaväes: OutMsg vs Translator vs NoMap Patterns

Kui teie rakenduse Elm hakatakse kasvama, soovite selle mõõtmete jagamiseks väiksemateks tükkideks laiali jagada. Kajasin seda teises ajaveebipostituses: TodoMVC struktureeritud näide koos Elmiga.

Osaliselt juhul, kui selle skaleerimisega kaasneb lõpuks vajadus saata MMS moodulist oma vanemale, näiteks juhul, kui konkreetse vaate navigeerimisnupud peavad saatma teate tipptasemel ruuterile.

Mõne aja pärast hakkasin märkama selle käsitlemiseks kolme erinevat mustrit ja kujundasin ümber Elm TodoMVC kõigi nende hoidla erinevate lähenemisviiside jaoks, et saaksite neid kõrvuti võrrelda.

OutMggi muster

Usun, et Folkertdev oli esimene, kes kirjutas Elmis laste ja vanemate suhtlusest kirjutavat, tema blogipostitus seletab seda lähenemist üsna hästi.

Kuid kokkuvõtlikult tagastate värskendusfunktsioonis lisaväärtuse. Nii et selle tagastamise asemel:

(Mudel, Cmd Msg)

Te tagastate selle:

(Mudel, Cmd Msg, OutMsg)

Seejärel vastutab nende värskendamise eest vanemvärskendusfunktsioon. Nii ei pea laps oma vanemast midagi teadma, vaid vanem peab teadma oma lapse OutMsgide kohta.

Olen TodoMVC seda lähenemisviisi rakendanud. Kuid kui soovite kontrollida selle reaalset ulatust, rakendas Richard Feldman elm-spa-näite sel viisil.

Teine näide, mis seda lähenemisviisi kasutab, on elm-datepicker.

Tõlkija muster

Tõlkija muster on väga sarnane väljuva sõnumiga, kuid selle asemel, et vanem teaks lapse sõnumite tüüpidest, edastab tõlkija kaudu vanem, kelle sõnumid luuakse. Alex Lew selgitab siin oma lähenemist palju paremini.

Põhimõtteliselt on teil tõlk, mis on selline rekord:

kirjuta varjunimi TranslationD Dictionary msg =
  {onInternalMessage: InternalMsg -> sõnum
  , onPlayerWin: Int -> sõnum
  , onPlayerLose: msg
  }

Olen seda lähenemisviisi rakendanud ka TodoMVC ja usun, et ka põldude automaatne täitmine on hea näide.

Vasar-vanem-laps-värskendus on raamatukogu, mis aitab teid lapsevanemate värskenduses, mis näib järgides seda mustrit.

NoMapi muster

Seda märkasin tehes. Põhiidee on hoiduda Cmd.map ja Html.map tegemisest, nii et selle asemel peavad kõik rääkima sama keelt, teisisõnu, teie värskendus- ja kuvamisfunktsioonid peavad tagastama Msg tipi.

Sellega on teil tõenäoliselt sellised sõnumid nagu MsgForLogin, MsgForRouter jne, nii et oma vaates teeksite midagi sellist:

nuppu [onClick (MsgForLogin SignUp)] []

Nii teadsin esimest korda TodoMVC uuesti, tegelikult kui ma esimest korda OutMggi nägin, ei saanud ma aru selle põhjusest, kuna ma ei kaardistanud oma MSg-sid.

Vaadake selle lähenemisviisi jaoks suuremat näidet välkkiire rakendusest. Samuti näib, et see rakendus järgib Kris Jenkinsi viisi Elmi rakenduste struktureerimiseks, mis soosib seda lähenemist, kuna ta eraldab failis Types.elm Msgs tüübid.

Elm-taco teegis kasutatakse OutMsg- ja NoMap-mustrite segu, omades tipptasemel „taco”, kuhu saab sõnumeid saata.

Vaatlused ja võrdlused

Neid mustreid uurides ja neile reageerides märkasin veel asju, millel võib olla eeliseid või miinuseid, sõltuvalt teie vajadustest:

  • NoMap-is on vanema värskendusfunktsioon sama, mis teie rakenduse kasvades, samal ajal kui OutMsg ja Translate abil võib vanema värskendusfunktsioon muutuda väga suureks, kuna peate hakkama saama iga lapse OutMsg-iga (näide)
  • OutMsg ja Tõlge sisestuspesades ei pea ülemistest vanematest midagi importima, muutes need kapseldatumaks, oleks lihtsam mõnda alamoodulit näiteks raamatukoguks ekstraheerida ja avaldada
  • NoMapi toimimiseks peaksid teie sõnumid elama värskendusest eraldi failina, vastasel juhul on teil sõltuvussilm. See on hea põhjus, mis sunnib teid asju jagama, kuid samal ajal halb, kui soovite, et iga mooduli jaoks oleks üks fail (Home.elm, Login.elm, Router.elm)
  • NoMapis on lihtsam sõnumeid kuhu tahes mujale saata, kuid võib olla raskem jälgida kõiki sellest põhjustatud oleku muutusi.
  • Nagu käesoleva kirjutise järgi mõõdetud, on TodoMVC reflektorite jaoks NoMap-lähenemisel 546 LOC, OutMsg 561 ja Tõlkija 612, kui see on teie jaoks oluline
  • NoMap-is peate lõpuks kasutama _ kõikehaaravat juhtumit, et ignoreerida teistest kohtadest pärit teateid, mida te ei soovi käsitleda, nii et kompilaatorist on vähem abi, ta ei saa öelda, mis teil puudu on (aitäh @mordrax osutamise eest see välja jalaka kohta)
  • Rakenduses OutMsg ja Translator saate lihtsalt vaadata tüüpe või tõlkijaid, et teada saada, milliseid lapse ja vanema suhtlusi on vaja, nii et koostaja juhendab teid nende rakendamisel, samas kui NoMapis on see suhtlus kaudsem
  • Tõlkija lähenemisviis näib olevat hea mõte, kui soovite oma MS-d anda välisele komponendile, näiteks täismõõdus
  • Tõlkija mustrit oli mul keeruline järgida, selle ehitamisel oli raske mõista Elmi kompilaatori veateateid
  • Kui te ei muuda (mudelit, Cmd Msg) standardit, saate kasutada peene tagastamise teeki
  • Mõned inimesed leiavad, et HTML-kaardi puudumine on hea tava, et vältida "komponentide" loomist
  • Nende lähenemisviiside segamisest saate palju kasu, näiteks võiksite lihtsalt vaadete vältimiseks kasutada HTML-i kaarti, kasutades värskendustena siiski OutMsg-i, või võite kasutada NoMap-i ainult kõrgema taseme sõnumite jaoks, kusjuures OutMsgs on allpool, välise tõlgitud komponendi renderdamise ajal

Ressursid

Ma usun, et lapsevanemate suhtlus on SPA-de suuruse muutmisel ja tegemisel sageli olulisem, sellepärast lugesin palju asju, mida lugesin selle reddit-lõime kohta, mis puudutab skaleerimise Elmi rakendusi:

Terviseks!