В тази публикация ще откриете как да използвате кутията с инструменти за асинхронно състояние, за да управлявате състояние с реакция, чрез куката за състояние useAsyncState.

Тази публикация е част от следната серия публикации в блога:

  1. асинхронни състояния: библиотека за управление на състоянието
  2. асинхронни състояния: Използване на реакция
  3. асинхронни състояния: Изходният обект
  4. асинхронни състояния: Производителят
  5. асинхронни състояния: Разширени концепции
  6. асинхронни състояния: срещу реагиране на заявка срещу редуциране срещу откат
  7. реагират-асинхронни състояния: SSR

Планирайте

  • Въведение
  • Използване на реакция и основната библиотека
  • useAsyncState
  • useSource
  • useProducer

Въведение

async-states беше написан първоначално като доказателство за концепцията в реакцията. Първата идея беше API, представен в предишната публикация, който основно отговаря на всичките ни нужди. След това узря достатъчно, за да бъде самостоятелен пакет, работещ във всички среди с кутия с инструменти за манипулиране на състоянието на ниско ниво (вътрешните пренаписвания са повече от 7 пъти, без въздействие върху външния API).

При изграждането на потребителски интерфейси най-честите случаи на употреба са абонамент за състояние, четене на неговите данни и вероятно манипулиране от различни места. Библиотеката покрива тези основни нужди чрез една кука, наречена useAsyncState, която приема два аргумента:

useAsyncState използва същия подпис като повечето реагиращи куки, така че използването е малко подобно. Има важна разлика, че deps за библиотеката по подразбиране е empty Array ([])а не undefined. Използва се за опресняване на вашата конфигурация в зависимост, като модела на реакцията.

Параметърът create може да бъде:

  • string, който идентифицира състояние чрез ключ
  • Функция producer
  • Обект source от createSource, Sources.for или useAsyncState
  • configuration обект, който комбинира цялата конфигурация на производителя и добавя специални за използване на реакцията.

Това позволява на библиотеката да създаде вашето състояние с пълен контрол във всеки компонент или всеки контекст на изпълнение с контекстуален полезен товар и аргументи!

Без ограничения и без трикове!

използване на реакция и основната библиотека

Ако си спомняте от предишната публикация, имаше използване на реакция директно с основната библиотека, която не зависи от реакцията, можете да правите неща като това:

За да вдигнем летвата още по-високо, ето един производител, който актуализира състоянието на интервален период:

Тествайте го тук! Дори написах websocket gateway, използвайки този модел! (Devtools също използва нещо подобно).

Можете също да се абонирате от vanilla javascript или всяко друго приложение в прозореца. Можем също така да създадем производители, които да изпращат съобщения до други прозорци/работници и да чакат техните отговори. Тези примери ще бъдат преразгледани в блога на производителя.

useAsyncState

Връщайки се към тази магическа кука, тя ви позволява

  • Създайте states достъпни навсякъде, които произвеждат стойности чрез super-powered производители.
  • Абонирайте се за тях, ако са били създадени преди това.
  • Изчакайте ги, ако желаете
  • Имате пъленпълен контрол над държавата

Ето най-често срещаните примери:

Базиран на маршрутизиране

Обичайният начин за извършване на връзки за търсене и споделяне е да добавите контекстуални неща към вашия URL адрес, след което да реагирате на промените им чрез любимия си рутер. „Ето как можете да го постигнете“:

Ако използвате зареждащите устройства и действията на react-router, тогава можете просто да направите нещо подобно:

Оптимистичен потребителски интерфейс

Възможността за създаване на оптимистичен потребителски интерфейс беше една от първите цели на библиотеката.

Производителят се захранва от вашите args и payload, които получава чрез своя параметър props. Всъщност копие на този props обект, съдържащ args и payload, се присвоява на вашето състояние всеки път.

Ако вашето състояние е success, вие имате реквизитите, довели до това състояние на успех (а също и за състояния error и aborted).

Ако погледнем назад към нашия пример за потребителско търсене, можем да направим неща като това:

Обектът state.props съдържа payload и args, така че в зависимост от това как е дефиниран вашият производител (да използвате който и да е от тях), ще можете да знаете какво е било предадено и доведено до това състояние. По последователен начин!

Търсете докато пишете

Със сигурност вече сте виждали това много пъти! Ето защо оставям този раздел на вас, можете да го направите!

Споделени състояния

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

Разгледайте този пример тук:

useAsyncState може да получи само ключ на state (низ) като параметър и да направи останалото вместо вас! Тествайте предишния пример тук.

събития

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

  • От изходния обект: можете да използвате метода on за регистриране на събития, поддържаните досега са: change (state change), cache-change (cache change), dispose(state is reset). Когато извикате on, той връща своето почистване, което ще премахне това събитие. Могат да се добавят няколко събития като: pre-change (with preventDefault and stopPropagation ;) ), pre-run (same) … и т.н.
  • От useAsyncState конфигурационен обект: конфигурационното свойство events позволява конфигуриране на събития от типове: change и subscribe (when your component actually subscribes to the state instance) . change може да се използва като обратни извиквания, когато състоянието се промени, а subscribe може да се използва за атака на host конкретни събития; като onFocus, onBlur … и така нататък.
  • От useAsyncState().onChange или useAsyncState().onSubscribe, които добавят допълнителни събития като от свойството конфигурация.

Нека да разгледаме някои примери:

Опитайте го сами тук! (просто потърсете идентификатор, по-голям от 10 или буквено-цифров, за да симулирате грешка)

Това „е малко еквивалентно“ на това:

Разликата е, че можете да контролирате кога да извикате onChange и това няма да зависи от изобразяването (но трябва разумно да поставите deps за useAsyncState, ако изберете това! използвайте на свой собствен риск!)

Забележка: Използването на събития като това може да бъде доста лошо, ако имате множество екземпляри, деклариращи това събитие и свързани към едно и също състояние: всички те ще бъдат изпълнени. За справяне с това съществува функцията runc!

Сега нека да разгледаме subscribe. Да кажем, че за предишния пример, когато излезете и се върнете в раздела след една секунда, ние опресняваме последните извлечени данни - Е, наистина ме дразни тази функция във всеки уебсайт на социални медии дни!). Това може да бъде толкова просто, колкото това:

Играйте с него тук! Моля, обърнете внимание, че onSubscribe и events.subscribe са същите като onChange и events.change

Без да използвате реакция, можете да се върнете към API на източника на ниско ниво: source.on. Използва се така:

Кеш памет

Трябва вече да сте запознати с кеша от предишните примери. Вътрешният тип зад него е:

Така че основно вие контролирате:

  • enabled: Дали да се активира кеша или не, трябва да се посочи изрично в случай на true
  • getDeadline: Функция, която връща количеството милисекунди, след което данните за състоянието трябва да бъдат изтрити (ако е поискано)
  • hash : Функция, която получава args и payload от изпълнението и изчислява своя кеш хеш
  • persist : В случай, че искате да запазите кеша си, използвайте тази функция, която се извиква всеки път, когато кешът се промени, с всички записи.
  • load : Функция, която първоначално зарежда кеша (може да е асинхронна)
  • onCacheLoads : Когато кешът се зарежда асинхронно, можете да прикачите това събитие, което например ще промени състоянието.

Забележка: Конфигурацията initialValue на състоянието получава кеша, така че ако можете синхронно да заредите кеш, можете да стартирате състоянието си от него.

useSource и useProducer

Що се отнася до имената им, тези куки се обясняват сами по себе си и са написани така в библиотеката:

Така че сега те са просто различни имена... (в миналото бяха различни, един и същ API, но не и една и съща реализация).

Заключение

Ако мислите за случай на употреба, който не разгледах в предишните примери, моля, уведомете ме, за да можем да го добавим.

След това нека видим как работи обектът source и как можем да го използваме.