Elmdə uşaq-valideyn ünsiyyəti: OutMsg vs Tərcüməçi və NoMap Nümunələr

Tətbiqiniz Elm böyüməyə başladıqda, miqyaslı ola bilmək üçün onu daha kiçik parçalara ayırmaq istəyəcəksiniz. Mən bunu başqa bir blogpostda əhatə etdim: Elm ilə qurulmuş TodoMVC nümunəsi.

Bu miqyaslandırma nəticədə bir moddan valideyninə bir mesaj göndərmə ehtiyacını ehtiva edərsə, məsələn, müəyyən bir görünüşdəki naviqasiya düymələri yuxarı səviyyəli Router-ə mesaj göndərməli olduqda.

Bir müddətdən sonra bu iş üçün 3 fərqli nümunəni görməyə başladım və Elm TodoMVC-ni bu depodakı bütün fərqli yanaşmalara düzəltdim ki, onları yan-yana müqayisə edə biləsiniz.

The OutMsg Nümunə

İnanıram ki, Folkertdev Elmdə uşaq-valideyn ünsiyyəti haqqında yazdığım ilk yazı idi, onun blogpostu bu yanaşmanı çox yaxşı izah edir.

Ancaq ümumiləşdirmək üçün əsasən yeniləmə funksiyanıza əlavə bir dəyər qaytarsınız. Buna görə bunu qaytarmaq əvəzinə:

(Model, Cmd Ms)

Bunu geri qaytarırsınız:

(Model, Cmd Ms, OutMsg)

Sonra, valideyn yeniləmə funksiyası bunların idarə olunmasına cavabdehdir. Bu yolla uşağın atası haqqında bir şey bilməsi lazım deyil, ancaq valideynin uşağının OutMsgs haqqında bilməsi lazımdır.

Bu yanaşmanı istifadə edərək TodoMVC tətbiq etdim. Ancaq bunun bir real dünya miqyasını yoxlamaq istəyirsinizsə, Richard Feldman elm-spa nümunəsini bu şəkildə tətbiq etdi.

Bu yanaşmadan istifadə edən başqa bir nümunə, qarağatçı xurmasıdır.

Tərcüməçi nümunəsi

Tərcüməçi Nümunəsi OutMsg modelinə çox bənzəyir, ancaq uşağın Msq növləri haqqında bilən valideyn əvəzinə, tərcüməçinin vasitəsi ilə Mss yaradılan keçidi valideyndir. Alex Lew burada yanaşmasını daha yaxşı izah edir.

Əsasən bu kimi bir qeyd olan bir tərcüməçiniz var:

növü alias TərcüməDordam msg =
  {onInternalMessage: InternalMsg -> msg
  , onPlayerWin: Int -> msg
  , onPlayerLose: msg
  }

Mən də bu yanaşmadan istifadə edərək TodoMVC tətbiq etdim və inanıram ki, avtoköçürmə də yaxşı bir nümunədir.

Elm-valideyn-uşaq yeniləməsi, bu nümunəni izləyən uşaq-valideyn yeniləməsi ilə sizə kömək edən bir kitabxanadır.

NoMap Nümunəsi

Bu etdiyimi fərq etdiyim bir şeydir. Əsas fikir Cmd.map və Html.map işlərini görməməkdir, bunun əvəzinə hamı eyni dildə danışmalı, başqa sözlə, yeniləmə və görüntü funksiyalarınızın üst səviyyəli Ms tipini qaytarmalı olacaqsınız.

Bununla, yəqin ki, MsgForLogin, MsgForRouter və s kimi Ms-lər olacaq, buna görə Görünüşünüzdə belə bir şey edərdiniz:

düyməsini [onClick (MsgForLogin SignUp)]] []

TodoMVC'i ilk dəfə necə reaktorlaşdırmışamsa, əslində OutMsg-i ilk dəfə gördüm, bunun səbəbini başa düşmədim, Ms-lərimi xəritələmədiyimə görə.

Bu yanaşma ilə daha böyük bir nümunə üçün ildırım-talk-tətbiqetməsini nəzərdən keçirin. Ayrıca, bu tətbiq Kris Jenkins'in Elm tətbiqlərini strukturlaşdırma yolunu izləyir, bu bir tip.elm faylında Mss növlərini ayırdığı üçün bu yanaşmanı dəstəkləyir.

Elm-taco kitabxanası kinoda, mesaj göndərə biləcəyiniz yüksək səviyyəli "taco" ilə OutMsg və NoMap nümunələrindən istifadə edir.

Müşahidələr və müqayisələr

Bu nümunələri araşdırarkən və təmizləyərkən ehtiyaclarınızdan asılı olaraq üstünlüklər və ya çatışmazlıqlar ola bilən şeyləri qeyd etdim:

  • NoMap-da, valideynin yeniləmə funksiyası, tətbiqiniz böyüdükcə eyni qalır, OutMsg və Tərcümə isə valideynlərin yeniləmə funksiyası çox böyük ola bilər, belə ki hər bir uşağın OutMsg-i idarə etməlisiniz (misal üçün)
  • OutMsg və Tərcümə içərisində quraşdırılmış modullar yuxarı valideynlərdən bir şey idxal etməyə ehtiyac duymur, onları daha əhatəli vəziyyətə gətirir, bəzi alt modulları bir kitabxana kimi çıxartmaq və yayımlamaq daha asan olardı.
  • NoMap-ın işləməsi üçün Ms-ların Yeniləmədən ayrı bir faylda yaşaması lazımdır, yoxsa başqa bir asılılıq halqa sahib olacaqsınız. Bu yaxşı bir səbəb, hər şeyi modul üçün bölüşdürməyə məcbur edir, eyni zamanda pisdir (Home.elm, Login.elm, Router.elm)
  • NoMap-da başqa bir yerə Ms göndərmək daha asandır, ancaq bunun səbəb olduğu bütün dövlət dəyişikliklərini izləmək daha çətin ola bilər.
  • Bu yazı yazıldığı anda ölçüldüyü kimi, TodoMVC reaktorları üçün NoMap yanaşması 546 LOC, OutMsg 561 və Translator 612-ə malikdir.
  • NoMap-da nəhayət _ tutmaq üçün bütün işlərdən istifadə etməlisiniz ki, Ms-ləri işləməyiniz istəmədiyiniz digər yerlərdən görməməzliyə vurursunuz, kompilyatordan az kömək olur, itkin düşdüyünüzü deyə bilmir (işarə üçün @mordrax üçün təşəkkürlər) ki, qarağacın üstündədir)
  • OutMsg və Tərcüməçidə yalnız uşaq və valideyn əlaqələrinin lazım olduğunu kəşf etmək üçün növlərə və ya tərcüməçilərə baxa bilərsiniz, buna görə tərtibçi bunları həyata keçirməyə istiqamətləndirə bilər, NoMap-da isə bu əlaqə daha açıqdır
  • Tərcüməçi yanaşması öz Ms-lərinizi elm-autocomplete kimi xarici komponentə vermək üçün yaxşı bir fikir kimi görünür
  • Tərtibatçı nümunəsini Elm tərtibçisindən səhv mesajları qurarkən başa düşmək üçün daha çətin izlədim
  • (Model, Cmd Msg) standartını dəyişdirməsəniz, incə qayıdan kitabxanadan istifadə edə bilərsiniz
  • Bəzi insanlar "komponentlər" yaratmamaq üçün Html.map-ı yaxşı təcrübə hesab etmirlər.
  • Bu yanaşmaları qarışdırmaqdan bir çox fayda əldə edə bilərsiniz, məsələn, yalnız görüntülər üçün Html.map-dan qaçınmaq olar, Yenə də yenilənmələr üçün OutMsg istifadə edərsən, ya da NoMap-ı yalnız yuxarı səviyyəli Mss üçün istifadə edə bilərsən, aşağıda OutMsgs ilə, xarici Tərcümə edilmiş bir komponent göstərərkən

Resurslar

Ölçəkləmə və SPAs edərkən Uşaq-Valideyn Rabitə daha tez-tez daha vacib olduğuna inanıram, buna görə tapdığım çox şey Elm Proqramlarını Ölçmə haqqında bu reddit ipini oxudu:

Salam!