Pāreja no Redux uz MobX

Kāpēc mēs esam šeit?

Agrāk vai vēlāk mēs to pārvietosim uz MobX stāvokli, tāpat kā tas tika darīts ar citām lietotnēm. Tāpēc es nolēmu to ātri apskatīt. Tur nebūs tik daudz kods šeit, un es uzskatu, ka jūs jau esat dzirdējuši par Redux. Sāksim.

Kas ir Redux?

Kā norādīts redux.js.org, tas ir “prognozējams konteinera stāvoklis attiecībā uz JS Aplikācijas.” To 2015. gadā izveidoja Dens Abramovs un Endrjū Klārks.
To var aprakstīt šādi. 3 principi:

1. Vienots patiesības punkts - stāvoklis tiek glabāts vienā krātuvē,
2. Stāvoklis ir tikai nolasāms - jūs nevarat tieši mainīt stāvokli, lai to izdarītu, ir jāizraida darbība,
3. Izmaiņas tiek veiktas ar tīrām funkcijām - tīrās funkcijas pēc definīcijas vienmēr atdod vienādus rezultātus dotajiem parametriem, tās var izpildīt vienmēr un tām nav blakusparādību.

Kas ir MobX?

Nekāds pārsteigums, MobX ir arī bibliotēka stāvokļa pārvaldībai, tā pārredzami izmanto funkcionālo reactive programmēšanu (TFRP), lai to padarītu vienkāršu un mērogojamu. Līdzīgi kā iepriekšējā bibliotēkā, tās filozofija ir aprakstīta 3 punktos:
1. Vienkārša - minimālistisks, bez katla kods un nav nepieciešami īpaši rīki, lai to darbinātu,
2. Viegli optimāla atveidošana - tā nodrošina, ka visi aprēķini ir labi optimizēti un nav nepieciešams to veikt manuāli,
3. Arhitektūras brīvība - implementācija ir neierobežota un to var izmantot bez UI ietvara.

MobX un Redux salīdzinājums

Mācības

React ir pazīstams ar nopietnu uzrakstu, kas saistīts ar sākotnējo iestatīšanu. To nedrīkst atstāt novārtā. Īpaši tad, ja jums ir lielāka lietojumprogramma ar daudziem reduktoriem un darbībām, jūs, iespējams, jau esat nolēmis saglabāt darbību tipus kā konstantes virknēs, kas ir laba pieeja, bet tad ir vēl vairāk koda! Par laimi. Redux rīku komplekts kļūst arvien populārāka, un tagad ir ieteicams rakstīt Redux loģika. Ja jūs man jautājat, man tas patīk! Joprojām ir daudz jāmācās, bet vienkāršā pamata iestatīšana ar rīku komplektu ir pietiekama.

Kad es paskatījos uz MobX dokumentācija, es biju kā bērns, kas nejauši nokļuvis šokolādes fabrikā. Es šķirstīju piemērus un jautāju, kā tas varētu darboties, bet tas darbojas, un acīmredzot tas darbojas labi. Bet varbūt visu reduktoru, darbību, starpprogrammu un citu sīkumu apstrāde ļauj tik viegli aizrauties ar kaut ko citu. Tomēr, ja jūs esat iepazinušies ar OOP, MobX jums būs pašsaprotami. Sākotnējā kodēšana ir daudz mazāka, un daudzas lietas notiek aizkulisēs, tāpēc vairumā gadījumu jums par tām nav jārūpējas.

Datu struktūra - kas ir valsts iekšienē?

In Redux, mums ir jāizmanto primitīvi, masīvi vai vienkārši JS objektus kā dati mūsu valstij.
Turklāt, uzglabājot datus masīvos, ir izplatīta prakse tos normalizēt veiktspējas apsvērumu dēļ. Diemžēl, pat izmantojot Redux rīku komplekta palīgfunkcijas (piem., createEntityAdapter), kas joprojām pievieno papildu kodu.

In MobX, mēs veidojam īpašības, veselus objektus, masīvus, Map un Sets. novērojams. Jā, primitīvi šeit nav minēti, jo to vērtības in JS ir nemainīgi, un tāpēc pret tiem ir jāizturas atšķirīgi. Viss, kas jums jāzina, ja izmantojat novērojams ir tas, ka primitīvs tiks ietīts “kastē”, un faktiskās vērtības getter un setter būs pieejams, izmantojot .get() un .set(newValue) attiecīgi skatīt observable.box(value)

importēt { observable, autorun } no "mobx"

const cityName = observable.box("Vienna") // tas pats, kas observable("Vienna")

autorun((() => {
    console.log(cityName.get())
})
// Izdrukā: 'Vīne'

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

Datu normalizēšana nav nepieciešama, jo MobX novērojams` klonē objektu, padara to novērojamu un tādējādi nodrošina, ka visas izmaiņas tiek atspoguļotas veikalā, tiklīdz mēs atjauninām jebkuru no novērojamajām īpašībām.

Datu atrašanās vieta - veikals(-i)

Mums ir vienots patiesības avots Redux. Uzturot stāvokli vienā vietā, mēs nodrošinām, ka dati netiek dublēti visā lietotnē, un to ir vieglāk atkļūdot.

MobX patiesībā ir ieteicams izveidot vismaz divus atsevišķus krātuves - vienu lietotāja saskarnes stāvoklim un vienu vai vairākas domēna stāvoklim. Šāda nodalīšana ļauj mums atkārtoti izmantot domēnu dažādās lietojumprogrammās.

Tā kā mēs neesam ierobežoti ar JS vienkāršiem objektiem, šķiet dabiski izveidot savas klases konkrētiem domēna objektiem, kā to iesaka autori. Šeit, Mobx spīd tiem, kam patīk objektorientēta programmēšana. Jūs varat izmantot metodes, kontrolēt, kas ir vai nav novērojams. Turklāt mēs varam apvienot vairākus veikalus un koplietot atsauces.

Nemainīgs un mainīgs

Redux pieprasa, lai valsts atjaunināšana nemutē sākotnējā stāvoklī. Tātad, ja mēs vēlamies pievienot jaunu elementu esošajam masīvam, mums ir jāatgriež jauna instance, nevis vienkārši jāpievieno šis elements esošajam.

funkcija todoReducer(state = [], action) {
    // šeit mēs izveidojam jaunu masīvu un izmantojam izplatīšanas operatoru, lai saglabātu vecās vērtības
    return [
      ...state,
     action.payload
    ]
}

Pēc tam MobX, mēs varam mutēt novērojamās īpašības, šeit:. todos masīvs. Ievērojiet, ka mēs mutējam sākotnējo masīvu addTodo

klase ObservableTodoStore {
  todos = [];

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


  addTodo(uzdevums) {
    // šeit mēs tikai pievienojam jaunu elementu esošajam masīvam!
    this.todos.push({
      uzdevums: uzdevums,
      completed: false,
    });
  }

}

const observableTodoStore = new ObservableTodoStore();
observableTodoStore.addTodo("Kāda grūta lieta, kas jādara");

Turklāt mēs varam pat tieši atjaunināt todo sarakstu, un mēs redzēsim, ka autorun tiks aktivizēts (tiks novērotas izmaiņas novērojamajā masīvā todos).

observableTodoStore.todos.push("Kāds cits grūts uzdevums");

// Kas ir vēl interesantāk, tikai tad, kad tiek atjaunināts konkrētais to-do īpašums
// MobX jūs brīdinās (stingrā režīmā), ka to nevajadzētu darīt tieši.
observableTodoStore.todos[1].task = ("Varbūt vēl kaut kas vieglāks");

Tīklošana

Personīgi man ļoti patīk Chrome Redux DevTools paplašinājums. Tas ļauj ātri apskatīt jūsu lietotnes stāvokli, un tam ir labas iespējas atgriezties un doties uz priekšu un atpakaļ, lai redzētu katru stāvokļa izmaiņu (ceļošana laikā!). Tas viss ir iespējams, pateicoties principam, ka jūs nemutējat iepriekšējo stāvokli.

Papildu abstrakcijas slānis veikalā apgrūtina atkļūdošanas procesu. Portāls MobX Chrome paplašinājums man šķiet tik apgrūtinoša, it īpaši, ja salīdzina ar iepriekšējo pieredzi, bet varbūt man ir nepieciešams laiks, lai pierastu pie tās.

Taču mums ir, piem. autorun funkcija, kuru, iespējams, bieži izmantosiet, kad sāksiet lietot MobX un vēlas pārbaudīt, kad stāvoklis mainās. Jāņem vērā, ka funkcija izseko tikai tās izmaiņas, kuras tā novēro. Tas tiek noteikts, kad funkcija tiek palaista pirmo reizi. MobX parakstīsies uz visiem novērojumiem, kas tika nolasīti pirmajā izsaukumā, un pēc tam tiks aktivizēts katru reizi, kad tie mainīsies.

Popularitāte

Aplūkojot popularitāti, Redux šeit dominē. Blakus 4M lejupielādes no npm nedēļā salīdzinājumā ar 450 tūkstoši MobX. Arī ieguldītāju skaits (~ 870 > 270) un zvaigžņu skaits (57k > 24k) katras bibliotēkas GitHub repozitorijā liecina, ka Redux ir labi pazīstams zīmols.

No otras puses, Ziņojums par stāvokli JS 2020 liecina, ka apmierinātība no to lietošanas ir gandrīz vienāda, tāpēc tas noteikti nepalīdzēs jums izlemt, kuru no tiem izvēlēties nākamajam darbam. projekts.

Apmierinātība šajā tabulā tika raksturota kā “izmantotu vēlreiz / (izmantotu vēlreiz + neizmantotu vēlreiz)”.”

Secinājums

Šajā konkursā nav uzvarētāju... vēl! BTW, tur nebija nekāda konkursa 😉 Es uzskatu, ka abas bibliotēkas dara lielisku darbu, izpildot savu pamatuzdevumu, kas ir rūpēties par to, lai jūsu bibliotēkā būtu stabils pārvaldības stāvoklis. JS lietojumprogramma . Man būs nepieciešams vairāk laika, lai redzētu, kā ikdienas darbs ar MobX atšķiras no Redux un kādos gadījumos es varētu to ieteikt.

Pagaidām es varu teikt, ka man jau pietrūkst “ceļošanas laikā” no Redux DevTools, bet, no otras puses, nosakot stāvokli ar MobX šķiet tik vienkāršs, un uzrakstītais kods izskatās daudz vieglāk lasāms.

Tomēr man ir ļoti interesanti, kā novērojams apstrādā veiktspēju, jo ikreiz, kad es redzu kādu burvju, es brīnos, cik daudz no mana datora resursiem (vai tas ir procesora laiks, atmiņa vai disks) tiek izmantoti un cik efektīvi tas ir. Tas noteikti būs mans nākamais izpētes posms.

Cerams, ka es atgriezīšos pie jums ar dažiem patiešām aizraujošiem skaidrojumiem par to, kā jūs varat atrisināt konkrētas problēmas ar MobX. Uz tikšanos!