Üleminek Reduxist MobXi

Miks me siin oleme?

Varem või hiljem, me liigutame selle üle MobX riik, nagu me tegime ka teiste rakenduste puhul. Seepärast otsustasin ma selle kiiresti üle vaadata. Seal ei ole nii palju kood siin ja ma usun, et olete juba kuulnud Redux. Alustame.

Mis on Redux?

Nagu märgitud aadressil redux.js.org, see on "ettearvatav konteineri olek JS rakendused." Selle lõid 2015. aastal Dan Abramov ja Andrew Clark.
Seda võib kirjeldada järgmiselt 3 põhimõtet:

1. Üks tõepunkt - riiki hoitakse ühes ja samas hoidlas,
2. Seisund on ainult lugemiseks - te ei saa seisundit otse muuta, selleks tuleb väljastada tegevus,
3. Muudatused tehakse puhaste funktsioonidega - puhtad funktsioonid annavad antud parameetrite puhul alati sama tulemuse, neid saab alati täita ja neil ei ole kõrvalmõjusid.

Mis on MobX?

See ei ole üllatus, MobX on samuti olekuhalduse raamatukogu, see rakendab läbipaistvalt funktsionaalset reaktiivset programmeerimist (TFRP), et muuta see lihtsaks ja skaleeritavaks. Sarnaselt eelnevale raamatukogule on selle filosoofia kirjeldatud 3 punktis:
1. Lihtne - minimalistlik, katlakivivaba kood ja selle kasutamiseks ei ole vaja spetsiaalseid tööriistu,
2. Mugav optimaalne renderdamine - see tagab, et kõik arvutused on hästi optimeeritud ja seda ei ole vaja käsitsi teha,
3. Arhitektuuriline vabadus - rakendamine on sõltumatu ja seda saab kasutada ilma kasutajaliidese raamistikuta.

MobX ja Redux võrdlus

Õppimine

React on tuntud tõsise keedukirjelduse poolest algseadistuse ümber. Te ei saa seda tähelepanuta jätta. Eriti kui teil on suurem rakendus, kus on palju reduktoreid ja tegevusi, olete ilmselt juba otsustanud hoida tegevuste tüübid konstandidena stringides, mis on hea lähenemine, kuid siis on veelgi rohkem koodi! Õnneks on Reduxi tööriistakomplekt muutub üha populaarsemaks ja nüüd soovitatakse kirjutada Redux loogika. Kui te küsite minult, siis mulle meeldib see! Siiski on palju õppida, kuid lihtne põhiseade koos tööriistakomplektiga teeb tööd.

Kui ma vaatasin MobXi dokumentatsioon, olin nagu laps, kes sattus kogemata šokolaadivabrikusse. Käisin näiteid läbi ja küsisin kogu aeg, kuidas see saab toimida, aga see toimib ja ilmselt toimib hästi. Aga võib-olla kõigi reduktorite, tegevuste, vaheprogrammide ja muude asjade käsitlemine teeb selle nii lihtsaks, et see on nii lihtne, et see paelub midagi muud. Sellegipoolest, kui sa oled OOP-ga tuttav, MobX tuleb teile loomulikult. Esialgset kodeerimist on palju vähem ja paljud asjad toimuvad kulisside taga, nii et te ei pea enamasti neist hoolima.

Andmestruktuur - mis on riigi sees?

Veebilehel Redux, peame kasutama primitiivseid, massiive või tavalisi JS objektid meie riigi andmeteks.
Samuti on andmete salvestamisel massiividesse levinud tava, nimelt nende normaliseerimine jõudluse tagamiseks. Kahjuks on isegi Reduxi tööriistakomplekti abifunktsioonidega (nt, createEntityAdapter), mis siiski lisab lisakoodi.

Veebilehel MobX, teeme omadused, terved objektid, massiivid, Map ja Sets vaadeldav. Jah, primitiive ei ole siinkohal mainitud, sest nende väärtused in JS on muutumatud ja seetõttu tuleb neid käsitleda erinevalt. Kõik, mida pead teadma, kui sa lähed koos jälgitav on see, et see mähib primitiivi "kasti" ja tegelik väärtus getter ja setter on saadaval läbi .get() ja .set(newValue) vastavalt vt observable.box(value)

import { observable, autorun } from "mobx"

const cityName = observable.box("Vienna") // sama mis observable("Vienna")

autorun(() => { {
    console.log(cityName.get())
})
// Prints: 'Vienna'

cityName.set("Amsterdam")
// Prints: 'Amsterdam'

Andmeid ei ole vaja normaliseerida, sest MobX jälgitav` kloonib objekti, muudab selle vaadeldavaks ja tagab seega, et kõik muudatused kajastuvad poes, kui me uuendame mõnda vaadeldavat omadust.

Andmete asukoht - kauplus(ed)

Meil on üks ja ainus tõeallikas Redux. Hoides olekut ühes kohas, tagame, et andmed ei dubleeriksid kogu rakenduses ja seda oleks lihtsam parandada.

MobX tegelikult julgustab vähemalt kahe eraldi hoidla olemasolu, üks kasutajaliidese seisundi jaoks ja üks või mitu domeeni seisundi jaoks. Selline eraldamine võimaldab meil domeeni taaskasutada erinevates rakendustes.

Kuna me ei ole piiratud JS tavaliste objektide jaoks tundub loomulik, et konkreetsete domeeni objektide jaoks luuakse oma klassid, nagu autorid soovitavad. Siin, Mobx paistab silma neile, kellele meeldib objektorienteeritud programmeerimine. Teil on meetodid, kontroll selle üle, mis peaks olema vaadeldav või mitte. Lisaks saame kombineerida mitut poodi ja jagada viiteid.

Muutumatu ja muutuv

Redux nõuab, et riigi ajakohastamine ei muteeru algne seisund. Seega, kui me tahame lisada uue elemendi olemasolevasse massiivi, peame tagastama uue eksemplari, selle asemel, et lihtsalt lisada see element praegusele.

function todoReducer(state = [], action) {
    // siin loome uue massiivi ja kasutame vanade väärtuste säilitamiseks levikuoperaatorit.
    return [
      ...state,
     action.payload
    ]
}

Siis, aastal MobX, saame muuta vaadeldavaid omadusi, siin: vaadeldavad omadused todos massiivi. Pange tähele, et me muudame algset massiivi addTodo

class ObservableTodoStore {
  todos = [];

  constructor() {
    makeObservable(this, {
      todos: observable,
      addTodo: action,
    });
    autorun(() => console.log(this.todos.length))
  }


  addTodo(task) {
    // siin me lihtsalt lükkame uue elemendi olemasolevasse massiivi!
    this.todos.push({
      task: task,
      completed: false,
    });
  }

}

const observableTodoStore = new ObservableTodoStore();
observableTodoStore.addTodo("Mingi raske asi, mida tuleb teha");

Veelgi enam, me saame isegi otse uuendada todo nimekirja ja me näeme, et autorun vallandatakse (see märkab muutust vaadeldavas massiivi todos).

observableTodoStore.todos.push("Some other tough task");

// Mis on veel huvitavam, ainult siis, kui uuendate konkreetse to-do omaduse
// hoiatab MobX sind (ranges režiimis olles), et sa ei tohiks seda otse teha.
observableTodoStore.todos[1].task = ("Võib-olla midagi veel vaevata");

Vigade kõrvaldamine

Mulle isiklikult meeldib Chrome Redux DevTools laiendus. See võimaldab teil kiiresti vaadata oma rakenduse olekut ja omab toredaid võimalusi, et minna tagasi ja edasi iga oleku muutuse puhul (ajarännak!). Kõik see on võimalik tänu põhimõttele, et te ei muuda eelmist olekut.

Poe täiendav abstraktsioonikiht muudab vigade kõrvaldamise protsessi keerulisemaks. Veebileht MobX Chrome'i laiendus tundub mulle nii kohmakas, eriti kui võrrelda seda eelneva kogemusega, aga võib-olla vajan ma aega, et sellega harjuda.

Kuid meil on näiteks autorun jälgimisfunktsioon, mida te tõenäoliselt palju kasutate, kui hakkate kasutama MobX ja tahavad kontrollida, millal seisund muutub. Peate tähele panema, et funktsioon jälgib ainult neid muutusi, mida ta jälgib. See määratakse kindlaks siis, kui funktsioon käivitub esimest korda. MobX tellib kõik vaatlusandmed, mida loeti esimese üleskutse ajal, ja seejärel käivitub see iga kord, kui need muutuvad.

Populaarsus

Kui vaadata populaarsust, siis Redux on siin ülekaalus. Lähedal 4M allalaadimist npm-st nädalas võrreldes 450k MobXi jaoks. Samuti näitab panustajate arv (~870 > 270) ja tärnide arv (57k > 24k) GitHubi repositooriumis iga raamatukogu puhul, et Redux on tuntud kaubamärk.

Teisest küljest, JS 2020 aruanne "State of JS 2020 näitab nende kasutamisest saadavat rahulolu peaaegu samal tasemel, nii et see ei aita kindlasti otsustada, millist neist valida oma järgmise projekt.

Rahulolu selles tabelis kirjeldati kui "kasutaksin uuesti / (kasutaksin uuesti + ei kasutaks uuesti)".

Kokkuvõte

Selles võistluses ei ole võitjaid... veel! BTW, ei olnud mingit võistlust üldse 😉 Ma usun, et mõlemad raamatukogud teevad suurepärast tööd oma põhiülesande täitmisel, mis on hoolitseda selle eest, et teie tahke haldusriik oleks kindel JS rakendus . Mul on vaja rohkem aega, et näha, kuidas igapäevane töö koos MobX erineb Redux ja millistel juhtudel ma võiksin seda soovitada.

Praegu võin öelda, et mul on juba puudu "ajarännak" Reduxi DevTools'ist, kuid teisest küljest on riigi seadmine koos MobX tundub nii lihtne ja kirjutatud kood tundub palju loetavam.

Sellegipoolest olen ma nii uudishimulik, kuidas jälgitav käsitleb jõudlust, sest iga kord, kui ma näen mingit maagiat, mõtlen ma, kui palju minu arvuti ressursse (olgu see siis protsessoriaeg, mälu või draiv) kasutatakse ja kui tõhus see on. See on kindlasti minu järgmine uurimisetapp.

Loodetavasti tulen teile tagasi mõne tõeliselt põneva selgitusega selle kohta, kuidas te saate lahendada konkreetseid probleeme koos MobX. Kohtumiseni!