Аполон срещу Редукс - визуализация с данни

Apollo и Redux са 2 популярни библиотеки, използвани с React. Те са включени по различни причини, но главно за:
1. Управление на магазин
2. Подпомагане на обработката на извличане на данни
3. Задействане на всяко повторно изобразяване с актуализирани реквизити

Но какви механизми използват под капака, за да направят това и как се различават, когато става въпрос за работа с реквизити и рендеринг?

Реших да проуча и по-долу е продуктът на това.

TLDR;

Аполон използва Наблюдаем и ръчно принуждава повторно визуализиране, като чете текущия Наблюдаем за данни в точка на рендер.

Redux също използва Observable, но актуализира местното състояние за своите абонати, като използва известия от наблюдатели.

наблюдаеми

Нещо, което трябва да се докосне първо, са наблюдателни. Те са нов примитив за асинхрон с някои мощни свойства. Основен пример е по-долу.

  1. Създайте своя наблюдаема от абонамент функция
const subscriptionFunction = (наблюдател) => {
   // направете някои неща, може да бъде асинхронизация.
   observer.next ("Обадете се с някои данни");
   observer.complete ();
   return () => console.log ("Отписване")
}
const ourObservable = new Observable (subscriptionFunction);

2. Абонирайте се за наблюдението си. Това ще се позове на subscriptionFunction.

const абонат = ourObservable.subscribe ({
   next (x) {console.log (x)}, // „Обаждане с някои данни“
   грешка (грешка) {console.log ("Получена крайна грешка на
   последователност. ")},
   complete () {console.log ("Потокът завърши успешно.")}
});
subscriber.unsubscribe (); // "Отписване"

По принцип можем да определим връзка между обекти между 1 и много. Когато състоянието се промени за родителя, наблюдаван, неговите зависими (наблюдатели) се уведомяват и актуализират.

Те имат няколко мощни свойства, включително това, че са мързеливи, отменяеми и могат да работят няколко пъти в последователност.

Вижте zen-наблюдение, за да се възползвате от тях по специфичен за днес начин.

Да започнем с Аполон

Apollo използва достъпа във функция за абонамент на Observables (намерете пълни подробности за вътрешните работи на Apollo в скорошна беседа, която проведох тук). Наблюдаваното служи и като Магазин за нормализирани данни.

При получаване на отговор от HTTP заявка, Store се актуализира и след това се задейства „forceRender ()” (Reacts метод за ръчно задействане на повторно изобразяване в даден компонент).

И накрая, използвайки „шаблона за рендериране на деца“, децата се предават с данни от текущия наблюдаем. Заслужава да се отбележи, че състоянието на React изобщо не е използвано тук.

Вижте по-долу за разбивка на събитията при зареждане на страница с основен компонент на заявката.

Пълна анатомия на зареждане на страница с Аполон

Сега към Redux

С Redux ще игнорираме действителния механизъм за извличане на HTTP (ако приемем, че за това се използват парчета или саги) и ще се съсредоточим върху актуализациите на магазина и рендерирането на компонентите.

Когато компонент „свързва ()“, той се добавя към списъка с абонати за Store Observable (повече за Redux Store Observable тук).
Когато редукторът се промени в магазина, всички абонати се известяват и изпълняват „setState ()“.

Резултатът е свързаният компонент и неговите деца се рендерират с актуализирани реквизити.

Опростена версия на свързването на Redux е по-долу:

клас Connect разширява компонент {
     trySubscribe () {
        this.unsubscribe =
          this.store.subscribe (this.handleChange.bind (тази))
        this.handleChange ()
     }
     компонентDidMount () {
       this.trySubscribe ()
     }
     handleChange () {
       const storeState = this.store.getState ()
       const prevStoreState = this.state.storeState
       // логика, използваща състояние за съхранение и реакция
       // ако състоянието на Store се е променило, актуализирайте състояние Reacts
       this.setState ({storeState})
     }
}

резюме

Струва ми се, че и двете библиотеки използват Observables, въпреки че го използват с различни механизми.

Мисля, че ако не друго, то показва вида на ролята на Observables в бъдещето на Javascript. Те са в етап 1 от официалното предложение в момента (подробни подробности на tc39 тук), така че да се надяваме, че скоро ще кацнат. Като се има предвид вида на силата, която те внасят в масата (решаването на проблеми, които Обещанията са потоци понякога не могат), изглежда, има голям брой сценарии, които ще бъдат подходящи за тях.

Четенето на работни примери за тях в природата, като това в Redux и Apollo, е чудесен начин да научите повече за тях.

На следващо място бих искал да разгледам плюсовете и минусите на тези подходи и да се опитам да разясня защо тези библиотеки избраха подхода, който са направили.

Ако това ви е харесало, моля, спестете плесница. Друга възможност да ме уведомите, ако имате някакви мисли или отзиви. Благодаря :)