Přechod z Reduxu na MobX

Proč jsme tady?

Dříve nebo později ji přesuneme do sekce MobX stejně jako u ostatních aplikací. Proto jsem se rozhodl, že se na to rychle podívám. Nebude toho tolik kód a věřím, že jste již slyšeli o Redux. Začněme.

Co je Redux?

Jak je uvedeno v redux.js.org, je to "předvídatelný stav kontejneru pro Aplikace JS." V roce 2015 ji vytvořili Dan Abramov a Andrew Clark.
Lze ji popsat takto 3 zásady:

1. Jediný bod pravdy - stav je uchováván v jediném úložišti,
2. Stav je pouze pro čtení - nelze jej přímo měnit, k tomu je třeba vyslat akci,
3. Změny se provádějí pomocí čistých funkcí - čisté funkce z definice vracejí vždy stejné výsledky pro dané parametry, lze je provádět vždy a nemají žádné vedlejší účinky.

Co je MobX?

Žádné překvapení, MobX je také knihovnou pro správu stavu, transparentně používá funkční reaktivní programování (TFRP), aby bylo jednoduché a škálovatelné. Podobně jako u předchozí knihovny je její filozofie popsána ve 3 bodech:
1. Přímočarý - minimalistický kód bez kotlů a žádné speciální nástroje,
2. Optimální vykreslování bez námahy - zajišťuje, aby byly všechny výpočty dobře optimalizovány a nebylo nutné je provádět ručně,
3. Volnost architektury - implementace je neomezená a lze ji použít bez jakéhokoli rámce uživatelského rozhraní.

Srovnání MobX a Redux

Učení

React je známý pro závažné problémy s počátečním nastavením. Nemůžete ji zanedbat. Zvláště pokud máte větší aplikaci s mnoha reduktory a akcemi, pravděpodobně jste se již rozhodli ponechat typy akcí jako konstanty v řetězcích, což je dobrý přístup, ale pak je kódu ještě více! Naštěstí Sada nástrojů Redux je stále populárnější a nyní se doporučuje psát Redux logika. Podle mě se mi to líbí! Přesto je třeba se toho hodně naučit, ale jednoduché základní nastavení pomocí sady nástrojů stačí.

Když jsem se podíval na Dokumentace MobX, byl jsem jako dítě, které se omylem ocitlo v továrně na čokoládu. Procházel jsem si příklady a pořád jsem se ptal, jak to může fungovat, ale funguje to a zřejmě to funguje dobře. Možná ale manipulace se všemi těmi reduktory, akcemi, middlewarem a dalšími věcmi způsobuje, že je tak snadné nechat se fascinovat něčím jiným. Nicméně pokud jste obeznámeni s OOP, MobX vám přijde přirozené. Počátečního kódování je mnohem méně a mnoho věcí se odehrává v zákulisí, takže se o ně ve většině případů nemusíte starat.

Struktura dat - co je uvnitř stavu?

Na adrese Redux, musíme použít primitiva, pole nebo obyčejná pole. JS objekty jako data pro náš stát.
Při ukládání dat do polí se také běžně používá normalizace z výkonnostních důvodů. Bohužel i s pomocnými funkcemi v sadě nástrojů Redux (např, createEntityAdapter), který stále přidává další kód.

Na adrese MobX, vytváříme vlastnosti, celé objekty, pole, Map a Sets. pozorovatelné. Ano, primitiva zde nejsou uvedena, protože jejich hodnoty v tabulce JS jsou neměnné, a proto je třeba s nimi zacházet odlišně. Vše, co potřebujete vědět, pokud půjdete s pozorovatelné je, že primitivum zabalí do "boxu" a skutečný getter a setter hodnoty bude k dispozici prostřednictvím .get() a .set(newValue) respektive viz observable.box(value)

import { observable, autorun } z "mobx"

const cityName = observable.box("Vienna") // totéž jako observable("Vienna")

autorun(() => {
    console.log(cityName.get())
})
// Vytiskne: 'Vídeň'

cityName.set("Amsterdam")
// Vytiskne: "Amsterdam

Normalizace dat není nutná, protože MobX pozorovatelné` objekt naklonuje, učiní jej pozorovatelným, a tím zajistí, že se všechny změny projeví v úložišti, jakmile aktualizujeme některou z pozorovatelných vlastností.

Umístění dat - sklad(y)

Máme jediný zdroj pravdy v Redux. Udržováním stavu na jednom místě zajistíme, že se data nebudou duplikovat po celé aplikaci, a usnadníme tak ladění.

MobX ve skutečnosti doporučuje mít alespoň dvě oddělená úložiště, jedno pro stav uživatelského rozhraní a jedno nebo více pro stav domény. Toto oddělení umožňuje nás k opakovanému použití domény v různých aplikacích.

Protože nejsme omezeni na JS prostých objektů, zdá se přirozené vytvořit vlastní třídy pro jednotlivé doménové objekty, jak navrhují autoři. Zde, Mobx pro ty z vás, kteří mají rádi objektově orientované programování. Můžete mít metody, kontrolu nad tím, co má být pozorovatelné a co ne. Navíc můžeme kombinovat více úložišť a sdílet reference.

Neměnné a proměnlivé

Redux vyžaduje, aby aktualizace stavu nemutuje původní stav. Chceme-li tedy přidat novou položku do existujícího pole, musíme vrátit novou instanci, a ne pouze přidat danou položku do stávajícího pole.

funkce todoReducer(state = [], action) {
    // zde vytvoříme nové pole a použijeme operátor rozprostření, abychom zachovali staré hodnoty
    return [
      ...state,
     action.payload
    ]
}

Pak v MobX, můžeme pozorovatelné vlastnosti mutovat, zde:. todos pole. Všimněte si, že původní pole mutujeme v addTodo

třída ObservableTodoStore {
  todos = [];

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


  addTodo(task) {
    //zde pouze přesuneme novou položku do stávajícího pole!
    this.todos.push({
      task: task,
      completed: false,
    });
  }

}

const observableTodoStore = new ObservableTodoStore();
observableTodoStore.addTodo("Nějaká těžká věc, kterou je třeba udělat");

A co víc, můžeme dokonce přímo aktualizovat todo a uvidíme, že autorun (zaznamená změnu v pozorovatelném poli parametru todos).

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

// Co je zajímavější, pouze při aktualizaci konkrétní vlastnosti to-do
// vás MobX upozorní (v přísném režimu), že byste to neměli dělat přímo
observableTodoStore.todos[1].task = ("Možná něco lehčího");

Ladění

Osobně se mi Chrome velmi líbí Rozšíření Redux DevTools. Umožňuje rychlý pohled na stav vaší aplikace a má příjemné funkce pro návrat tam a zpět pro každou změnu stavu (cestování v čase!). To vše je možné díky principu, že předchozí stav nemutujete.

Další vrstva abstrakce úložiště ztěžuje proces ladění. Na adrese Rozšíření MobX pro Chrome zdá se mi to těžkopádné, zejména ve srovnání s předchozími zkušenostmi, ale možná potřebuji nějaký čas, abych si na to zvykl.

Ale máme např. autorun funkce sledování, kterou pravděpodobně budete často používat, až začnete používat funkci MobX a chcete zkontrolovat, kdy se stav změní. Je třeba si uvědomit, že funkce bude sledovat pouze změny, které pozoruje. Ta je určena, jakmile funkce poprvé proběhne. MobX se přihlásí ke všem pozorovatelným objektům, které byly načteny během prvního volání, a pak se spustí při každé jejich změně.

Popularita

Když se podíváte na popularitu, převažuje zde Redux. Poblíž 4M stažení od npm za týden ve srovnání s 450k pro MobX. Také počet přispěvatelů (~870 > 270) a hvězdiček (57k > 24k) v repozitáři GitHub pro každou knihovnu ukazuje, že Redux je dobře známá značka.

Na druhou stranu, Zpráva o stavu JS 2020 ukazuje spokojenost s jejich používáním na téměř stejné úrovni, takže vám rozhodně nepomůže při rozhodování, který z nich si vybrat pro svůj příští projekt. projekt.

Spokojenost v tomto grafu byla popsána jako "použil bych znovu / (použil bych znovu + nepoužil bych znovu)".

Závěr

V této soutěži zatím nejsou vítězové! BTW, žádná soutěž se nekonala 😉 Myslím, že obě knihovny odvádějí skvělou práci a plní svůj základní úkol, tedy starají se o to, abyste měli ve svém počítači solidní správu. Aplikace JS . Budu potřebovat více času, abych viděl, jak denně pracovat s MobX se liší od Redux a pro které případy bych ji mohl doporučit.

Prozatím mohu říci, že mi již chybí "cestování v čase" z DevTools Reduxu, ale na druhou stranu nastavení stavu pomocí MobX vypadá tak jednoduše a napsaný kód je mnohem čitelnější.

Přesto jsem zvědavá, jak se pozorovatelné zvládá výkon, protože kdykoli vidím nějaké kouzlo, zajímá mě, kolik prostředků mého počítače (ať už jde o čas procesoru, paměť nebo disk) je využito a jak je to efektivní. To bude určitě moje další fáze výzkumu.

Doufám, že se vám ozvu s nějakým opravdu zajímavým vysvětlením, jak můžete vyřešit konkrétní problémy s. MobX. Tak na shledanou!