Gå fra Redux til MobX

Hvorfor er vi her?

Før eller senere vil vi flytte den til MobX tilstand, akkurat som vi gjorde med de andre appene. Derfor bestemte jeg meg for å ta en rask titt på den. Det vil ikke være så mye kode her, og jeg tror du allerede har hørt om Redux. La oss begynne.

Hva er Redux?

Som nevnt på redux.js.orger det "en forutsigbar tilstand av container for JS Apps." Den ble skapt av Dan Abramov og Andrew Clark i 2015.
Det kan beskrives ved 3 prinsipper:

1. Ett sannhetspunkt - tilstanden oppbevares i ett enkelt lager,
2. Tilstanden er skrivebeskyttet - du kan ikke endre tilstanden direkte, du må sende ut en handling for å gjøre det,
3. Endringer gjøres med rene funksjoner - rene funksjoner returnerer per definisjon alltid det samme resultatet for gitte parametere, kan alltid utføres og har ingen bivirkninger.

Hva er MobX?

Ingen overraskelse her, MobX er også et bibliotek for tilstandsstyring, men det bruker funksjonell reaktiv programmering (TFRP) for å gjøre det enkelt og skalerbart. På samme måte som det foregående biblioteket, er filosofien beskrevet i tre punkter:
1. Enkel - minimalistisk, kjelefri kode og ingen spesialverktøy kreves for å bruke den,
2. Optimal gjengivelse uten problemer - den sørger for at alle beregninger optimaliseres godt, og det er ikke nødvendig å gjøre det manuelt,
3. Arkitektonisk frihet - implementeringen er ikke detaljstyrt og kan brukes uten rammeverk for brukergrensesnitt.

Sammenligning av MobX og Redux

Læring

React er kjent for den alvorlige boilerplate rundt den første installasjonen. Du kan ikke forsømme det. Spesielt når du har en større applikasjon med mange reduksjonsmaskiner og handlinger, har du sannsynligvis allerede bestemt deg for å beholde handlingstypene som konstanter i strengene, noe som er en god tilnærming, men da blir det enda mer kode! Heldigvis kan Redux-verktøysett blir stadig mer populært, og det anbefales nå å skrive Redux logikk. Hvis du spør meg, så liker jeg det! Det er fortsatt mye å lære, men det enkle grunnoppsettet med Toolkit gjør jobben.

Da jeg så på MobX-dokumentasjonJeg var som et barn som ved et uhell hadde havnet i en sjokoladefabrikk. Jeg gikk gjennom eksemplene og spurte hele tiden hvordan det kunne fungere, men det gjør det, og tilsynelatende gjør det det bra. Men kanskje er det håndteringen av alle reduksjonsmaskiner, actions, middlewares og andre ting som gjør det så lett å bli fascinert av noe annet. Uansett, hvis du er kjent med OOP, MobX vil komme naturlig for deg. Det er mye mindre innledende koding, og mange ting skjer bak kulissene, slik at du i de fleste tilfeller ikke trenger å bry deg om dem.

Datastruktur - hva er inne i staten?

I Reduxmå vi bruke primitiver, matriser eller vanlige JS objekter som data for vår stat.
Det er også vanlig praksis når du lagrer data i matriser, nemlig å normalisere dem av ytelseshensyn. Dessverre, selv med hjelpefunksjonene i Redux Toolkit (f.eks, createEntityAdapter) som fortsatt legger til ekstra kode.

I MobXlager vi egenskaper, hele objekter, matriser, Map og Sets observerbar. Ja, primitiver er ikke nevnt her fordi verdiene deres i JS er uforanderlige, og derfor må de behandles forskjellig. Alt du trenger å vite hvis du velger en observerbar er at den vil pakke primitiven inn i "en boks", og den faktiske verdiinnhenteren og verdisetteren vil være tilgjengelig via .get() og .set(newValue) henholdsvis se observable.box(verdi)

import { observable, autorun } fra "mobx"

const cityName = observable.box("Wien") // samme som observable("Wien")

autorun(() => {
    console.log(cityName.get()))
})
// Skriver ut: 'Wien'

cityName.set("Amsterdam")
// Skriver ut: 'Amsterdam'

Det er ikke behov for normalisering av data, ettersom MobX observerbar` kloner objektet, gjør det observerbart og sørger derfor for at alle endringer gjenspeiles i butikken når vi oppdaterer noen av de observerbare egenskapene.

Plassering av data - butikk(er)

Vi har en eneste kilde til sannhet i Redux. Ved å samle statusen på ett sted sørger vi for at dataene ikke dupliseres over hele appen, og det blir enklere å feilsøke.

MobX oppfordrer faktisk til å ha minst to separate lagre, ett for brukergrensesnittets tilstand og ett eller flere for domenets tilstand. Denne separasjonen gjør at vi kan gjenbruke domenet i ulike applikasjoner.

Fordi vi ikke er begrenset til JS vanlige objekter, virker det naturlig å lage egne klasser for bestemte domeneobjekter, slik forfatterne foreslår. Se her, Mobx er perfekt for deg som liker objektorientert programmering. Du kan ha metoder, kontroll over hva som skal være observerbart eller ikke. I tillegg kan vi kombinere flere butikker og dele referansene.

Uforanderlig og foranderlig

Redux krever at oppdateringen av tilstanden muterer ikke den opprinnelige tilstanden. Så hvis vi vil legge til et nytt element i en eksisterende matrise, må vi returnere en ny forekomst i stedet for bare å legge til elementet i den nåværende.

function todoReducer(state = [], action) {
    // her oppretter vi en ny matrise og bruker en spread-operator for å beholde de gamle verdiene
    return [
      ...state,
     action.payload
    ]
}

Deretter, i MobXkan vi mutere de observerbare egenskapene, her: den todos matrise. Legg merke til at vi muterer den opprinnelige matrisen i addTodo

class ObservableTodoStore {
  todos = [];

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


  addTodo(task) {
    //her skyver vi bare det nye elementet til den eksisterende matrisen!
    this.todos.push({
      oppgave: oppgave,
      completed: false,
    });
  }

}

const observableTodoStore = new ObservableTodoStore();
observableTodoStore.addTodo("En vanskelig ting å gjøre");

Dessuten kan vi til og med oppdatere gjøremål listen, og vi vil se at autorun vil bli avfyrt (den vil legge merke til en endring i den observerbare matrisen til todos).

observableTodoStore.todos.push("En annen vanskelig oppgave");

// Det som er mer interessant, er at bare når du oppdaterer den bestemte to-do-egenskapen
// vil MobX advare deg (mens du er i streng modus) om at du ikke bør gjøre det direkte
observableTodoStore.todos[1].task = ("Kanskje noe mer uanstrengt");

Feilsøking

Personlig liker jeg Chrome veldig godt Redux DevTools-utvidelse. Den lar deg ta en rask titt på appens tilstand og har fine muligheter til å gå frem og tilbake for hver endring i tilstanden (tidsreise!). Alt dette er mulig på grunn av prinsippet om at du ikke muterer den forrige tilstanden.

Det ekstra abstraksjonslaget til butikken gjør feilsøkingsprosessen vanskeligere. Det MobX Chrome-utvidelse virker så tungvint for meg, spesielt sammenlignet med den tidligere opplevelsen, men kanskje jeg trenger litt tid til å venne meg til det.

Men vi har f.eks. autorun sporfunksjon som du sannsynligvis vil bruke mye når du begynner å bruke MobX og ønsker å sjekke når tilstanden endres. Vær oppmerksom på at funksjonen bare sporer de endringene den observerer. Det avgjøres når funksjonen kjøres for første gang. MobX abonnerer på alle observabler som ble lest under det første påkallet, og deretter utløses den hver gang de endres.

Popularitet

Når du ser på populariteten, er det Redux som vinner her. Nær 4 millioner nedlastinger fra npm per uke sammenlignet med 450 000 for MobX. Også antall bidragsytere (~870 > 270) og stjerner (57k > 24k) på GitHubs repository for hvert bibliotek viser at Redux er et velkjent varemerke.

På den annen side.., Rapporten State of JS 2020 viser at tilfredsheten med å bruke dem er nesten like stor, så det vil definitivt ikke hjelpe deg med å bestemme hvilken du skal velge til din neste prosjekt.

Tilfredsheten i dette diagrammet ble beskrevet som "ville brukt igjen / (ville brukt igjen + ville ikke brukt igjen)"

Konklusjon

Det er ingen vinnere i denne konkurransen ... ennå! BTW, det var ingen konkurranse i det hele tatt 😉 Jeg tror begge bibliotekene gjør en god jobb med å utføre sin grunnleggende oppgave, som er å ta vare på å ha en solid administrasjonstilstand i din JS-applikasjon . Jeg trenger mer tid for å se hvordan det daglige arbeidet med MobX skiller seg fra Redux og i hvilke tilfeller jeg kan anbefale det.

Foreløpig kan jeg si at jeg allerede savner "tidsreisen" fra Reduxs DevTools, men på den annen side setter jeg en tilstand med MobX virker så grei, og den skrevne koden ser mye mer lesbar ut.

Likevel er jeg så nysgjerrig på hvordan observerbar håndterer ytelsen, for hver gang jeg ser noe magisk, lurer jeg på hvor mye av ressursene på PC-en min (enten det er CPU-tid, minne eller harddisk) som brukes og hvor effektivt det er. Det vil definitivt være min neste fase av forskning.

Forhåpentligvis vil jeg komme tilbake til deg med noen virkelig spennende forklaringer på hvordan du kan løse spesielle problemer med MobX. Da ses vi!