Преди да преминем към теорията, имаме Repo с демонстрация, за да покажем разликата между Recoil&Redux. Опитайте също да стартирате приложение, за да видите как новите функции от Recoil правят разликата.
Ефективност
Абонаментите за Recoil са за актуализации на атом/селектор, докато в Redux са за всички действия. Така че, ако имате N свързан компонент и изпратите действие, което трябва да задейства само един компонент, дори ако повторното изобразяване е спряно от оптимизацията на useSelector, redux трябва да изпълни N обратни извиквания на абонамент.
Шифов код
Може да имате по-малко от 5x шаблон с redux, с много обвивки като RTK или redux-query, но дори и това ще напишете по-малко код, по-мощен с откат. Set(atom, value), Execute Task са много по-лесни концепции за управление от диспечиране, действия, редуктори, саги и т.н...
Създадох repo, за да подчертая разликата.
Крива на обучение
Високо в Redux, тъй като Recoil следва принципите на React, така че Recoil включва по-малко крива на обучение. В Redux трябва да разберем потока за актуализиране на състоянието с помощта на действия и трябва да овладеем потока от край до край, както и да покажем на диаграмата по-долу.
Асинхронна поддръжка
В Redux можем да се свържем с помощта на redux-saga за постигане на асинхронна поддръжка за отделяне на механизма за извикване на api в приложението React.
В Recoil имаме механизъм за обработка на асинхронни вътрешно, където ми се стори наистина интересно с помощта на селектори
Можете да проверите с repo за повече разбиране.
Състояние
Имаме глобално хранилище в Redux, Всичко се съхранява в хранилище, което е наистина ефективно, където Recoil предоставя индивидуална абонаментна/променлива единица на състоянието с атоми и селектори. Състоянията на откат, използващи 10 000 атома, също са много ефективни.
източник: https://recoiljs.org/blog#scaling-to-large-numbers-of-atoms
Междинен софтуер
Redux идва с поддръжка на междинен софтуер като redux-thunk/redux-saga. Което разделя механизма за извикване на api от приложението, което лесно може да се тества. Recoil вътрешно се справя с много неща за обработка на състоянието на зареждане, докато извиква api, който се използва за показване на товарач, докато данните се извлекат. Също така за асинхронна операция можем да използваме селектори, които са много здрави.
Запаметен
Кеширането може да се управлява с помощта на библиотеката повторно избиране за състояние на Redux, Reselect кешира изхода спрямо предоставения му вход. Ако имаме функция за добавяне и я извикваме с параметър 3,5, тя ще върне 8. Следващия път, ако извикате същата функция с 3,5, тя няма да изчисли отново стойността, а ще върне кешираната стойност, която се обработва вътрешно в Recoil. За това нямате нужда от библиотека на трета страна.
В рамките на нашето repo, когато се опитаме да извикаме api от async селектор, той ще извика само първия монтиран компонент, по-късно ще върне кешираната стойност.
Заключение
Откатът все още е в експериментална фаза и можем да го проследим тук. Когато Redux е много стабилно състояние. Като се има предвид експерименталната фаза, която все още се използва от много разработчици, както и от Facebook в производството, мисля, че може да замени. Какво мислиш? Моля, споделете вашите мисли чрез коментари.
Полезни връзки
1. Хранилище
