Að færa sig úr Redux yfir í MobX

Af hverju erum við hér?

Fyrr eða síðar munum við færa það til MobX ástand, rétt eins og við gerðum með hin forritin. Þess vegna ákvað ég að kíkja fljótt á það. Það verður ekki svo mikið kóði hér og ég tel að þú hafir þegar heyrt um Endurtekning. Skulum byrja.

Hvað er Redux?

Eins og fram kemur hjá redux.js.org, það er “fyrirsjáanlegt ástand íláts fyrir JS Forrit.Það var búið til af Dan Abramov og Andrew Clark árið 2015.
Það má lýsa því með 3 meginreglur:

1. Einn sannleikspunktur – ástandið er geymt í einni gagnageymslu,
2. Ástandið er eingöngu til lestrar – þú getur ekki breytt ástandinu beint, þú ættir að senda aðgerð til þess.,
3. Breytingar eru gerðar með hreinum fallum – hrein fall eftir skilgreiningu skila alltaf sömu niðurstöðum fyrir gefnar breytur, má framkvæma þau hvenær sem er og þau hafa engin aukaverkun.

Hvað er MobX?

Engin furða hér, MobX er einnig bókasafn fyrir ástandsstjórnun, sem gerir hagnýta reactíva forritun (TFRP) gagnsætt til að gera hana einfalda og stækkanlega. Á svipaðan hátt og í fyrrnefnda bókasafninu er heimspeki þess lýst í þremur liðum:
1. Einfaldur – lágmarkskóði án upphitunartanka og engin sérverkfæri nauðsynleg til reksturs.,
2. Óaðfinnanleg hágæðagerð – tryggir að allar útreikningar séu vel fínstilltar og ekki þarf að stilla þær handvirkt,
3. Arkitektúrfrelsi – innleiðing er hlutlaus og má nota án nokkurs notendaviðmótsramma.

Samanburður á MobX og Redux

Læring

React er þekkt fyrir alvarlega staðalskriftu í upphaflegri uppsetningu. Þú getur ekki hunsað hana. Sérstaklega þegar þú ert með stærri forrit með mörgum reducerum og actions, hefurðu líklega þegar ákveðið að halda action-gerðum sem stöðugum strengjum, sem er góð nálgun, en þá er enn meiri kóði! Sem betur fer, Redux Toolkit er að verða sífellt vinsælli og nú er mælt með að skrifa Endurtekning Rökfræði. Ef þú spyrð mig, líkar mér það! Enn er margt til að læra, en einföld grunnuppsetning með Toolkit-inu dugar til verksins.

Þegar ég leit á MobX skjöl, Ég var eins og barn sem óvart lenti í súkkulaðiverksmiðju. Ég fór í gegnum dæmin og hélt áfram að spyrja hvernig þetta gæti virkað, en það virkar og virðist gera það vel. En kannski gerir það að takast á við alla reducers, actions, middlewares og annað slíkt svo auðvelt að láta hugann reika til annarra hluta. Engu að síður, ef þú þekkir OOP, MobX Mun koma þér náttúrulega. Upphafleg kóðun er mun minni og margt gerist bak við tjöldin, svo þú þarft í flestum tilfellum ekki að hafa áhyggjur af því.

Gagnasafn – hvað er í ástandinu?

Í Endurtekning, við verðum að nota frumgerðir, fylki eða einfaldar JS hlutir sem gögn fyrir ríki okkar.
Einnig er algengt að þegar gögnum er safnað í fylki sé þeim normalíserað til að bæta frammistöðu. Því miður, jafnvel með hjálparföllunum í Redux Toolkit (t.d., búa til Entity-millilið) sem samt bætir við auka kóða.

Í MobX, við bætum við eignir, heilar hluti, fylki, kort og safna Sjáanlegt. Já, frumgerðir eru ekki nefndar hér vegna gilda þeirra í JS eru óbreytanlegir og þess vegna þarf að meðhöndla þá á annan hátt. Allt sem þú þarft að vita ef þú velur Sjáanlegur er að það mun pakka frumgerðinni í “kassa” og raunverulegir gildislesari og gildissetjari verða aðgengilegir í gegnum .fá() og .set(newValue) í samræmi við sjá observable.box(value)

import { observable, autorun } from "mobx"

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

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

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

Ekki er þörf á að normalísera gögnin, þar sem MobX SjáanlegurAfritar hlutinn, gerir hann áberandi og tryggir þannig að allar breytingar endurspeglast í geymslunni þegar við uppfærum einhverja áberandi eiginleika.

Staðsetning gagna – verslun(ar)

Við höfum einn sannleikansuppsprettu í Endurtekning. Með því að halda ástandinu á einum stað tryggjum við að gögnin séu ekki endurtekin um allt forritið og auðveldara verður að rekja villur.

MobX Hvetur í raun til að hafa að minnsta kosti tvær aðskildar geymslur, eina fyrir UI-ástandið og eina eða fleiri fyrir sviðsástandið. Sú aðskilnaður gerir kleift okkur að endurnýta léninu í mismunandi forritum.

Vegna þess að við erum ekki takmörkuð við JS Fyrir einföld hluti virðist eðlilegt að búa til sínar eigin klassa fyrir tilteknar sviðshluti, eins og höfundarnir benda á. Hér, Mobx Skín fyrir ykkur sem hafið gaman af hlutbundinni forritun. Þið getið haft aðferðir og stjórn á því hvað skuli vera sýnilegt eða ekki. Auk þess getum við sameinað marga geymslur og deilt vísunum.

Óbreytanlegt og breytanlegt

Endurtekning krefst þess að ríkið uppfæri breytist ekki upprunalegu ástandinu. Svo, ef við viljum bæta nýjum lið við núverandi fylki, þurfum við að skila nýrri instans í stað þess að bæta einfaldlega þeim lið við núverandi fylkið.

function todoReducer(state = [], action) {
    // hér bætum við við nýjan fylki og notum dreifingar-operatórinn til að varðveita gömlu gildin
    return [
 ...state,
 action.payload
    ]
}

Síðan, í MobX, við getum stökkbreytt áberandi eiginleikana, hér: the allir rað. Athugaðu að við breytum upprunalega röðinni í bæta við verkefnalista

class ObservableTodoStore {
  todos = [];

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


  addTodo(task) {
    //hér erum við bara að bæta nýja atriðinu við núverandi fylkið!
    this.todos.push({
 task: task,
 completed: false,
    });
  }

}

const observableTodoStore = new ObservableTodoStore();
observableTodoStore.addTodo("Some tough thing to do");

Enn fremur getum við jafnvel uppfært hann beint. Verkefnalisti listi og við munum sjá að sjálfræsla verður rekinn (hann mun taka eftir breytingu í sýnilegu fylki af allir).

observableTodoStore.todos.push("Eitthvað annað krefjandi verkefni");

// Það sem er enn áhugaverðara er að MobX gefur þér aðvörun (í ströngu ham)
// aðeins þegar þú uppfærir tiltekna eiginleika verkefnalistans
// um að þú ættir ekki að gera það beint
observableTodoStore.todos[1].task = ("Kannski eitthvað sem krefst minni fyrirhafnar");

Vigslun

Persónulega líkar mér mjög vel við Chrome. Redux DevTools-viðbót. Það gerir þér kleift að kíkja fljótt á ástand forritsins þíns og býður upp á góða möguleika til að fara fram og til baka við hverja breytingu á ástandinu (tímaferðalög!). Allt þetta er mögulegt vegna þeirrar meginreglu að þú breytir ekki fyrra ástandi.

Viðbótar abstraktunarlag í versluninni gerir ferlið við villuleit erfiðara. The MobX Chrome-viðbót Mér finnst þetta svo klunnalegt, sérstaklega miðað við fyrri reynslu, en kannski þarf ég smá tíma til að venjast því.

En við höfum, t.d., hinn sjálfræsla eftirlitsvirkni sem þú munt líklega nota mikið þegar þú byrjar að nota MobX og vilja athuga hvenær ástandið breytist. Þú þarft að taka eftir því að fallið mun aðeins fylgjast með þeim breytingum sem það skynjar. Það ákvarðast þegar fallið keyrir í fyrsta sinn. MobX mun gerast áskrifandi að öllum áhorfandanlegum gildum sem lesin voru við þá fyrstu köllun og verður síðan kallað í hvert sinn sem þau breytast.

Vinsældir

Þegar þú skoðar vinsældirnar, er Redux hér ráðandi. Nálægt 4M niðurhal frá npm á viku borið saman við 450 þúsund fyrir MobX. Einnig sýnir fjöldi framlagshafa (~870 vs. 270) og stjörna (57 þús. vs. 24 þús.) á GitHub-geymslu hvers bókasafns að Redux er vel þekkt vörumerki.

Á hinn bóginn, Skýrsla um ástand JS 2020 sýnir ánægju af notkun þeirra á nánast sama stigi, svo það mun vissulega ekki hjálpa þér að ákveða hvaða á að velja fyrir næstu verkefni.

Anægjan í þessari töflu var lýst sem “myndi nota aftur / (myndi nota aftur + myndi ekki nota aftur)”

Ályktun

Það eru engir sigurvegarar í þessu keppni… ennþá! Að auki var engin keppni 😉 Ég tel að báðar bókasöfnin séu að standa sig frábærlega í að sinna grunnverkefni sínu, sem er að sjá til þess að viðhalda traustum stjórnunarstöðu í þínu JS-forrit . Ég mun þurfa meiri tíma til að sjá hvernig dagleg vinna með MobX er ólíkt Endurtekning og í hvaða tilvikum ég gæti mælt með því.

Fyrir nú get ég sagt að mér skorti nú þegar “tímaferðalag” úr DevTools í Redux, en aftur á móti að stilla ástand með MobX Þetta virðist svo einfalt og kóðinn sem skrifaður er lítur mun læsilegri út.

Engu að síður er ég svo forvitinn um hvernig Sjáanlegur sem sér um frammistöðuna, því hvenær sem ég sé töfrum undrast ég hversu mikið af auðlindum tölvunnar minnar (hvort sem um er að ræða örgjörva­tíma, vinnsluminni eða harða diskinn) er notað og hversu skilvirkt það er. Það verður án efa næsta stig rannsókna minna.

Vonandi mun ég koma til baka til þín með nokkrar virkilega spennandi skýringar á því hvernig þú getur leyst ákveðin vandamál með MobX. Sjáumst þá!