Прежде чем мы перейдем к теории, у нас есть Repo с демонстрацией, чтобы показать разницу между Recoil и Redux. Также попробуйте запустить приложение, чтобы увидеть, как новые функции от Recoil имеют значение.
Производительность
Подписки Recoil относятся к средствам обновления атомов/селекторов, а в Redux — ко всем действиям. Таким образом, если у вас есть N подключенных компонентов и вы отправляете действие, которое должно запускать только один компонент, даже если повторный рендеринг остановлен оптимизацией useSelector, избыточность должна выполнять N обратных вызовов подписки.
Шаблонный код
У вас может быть менее 5-кратного шаблона с редуксом, со многими обертками, такими как RTK или редукс-запрос, но даже при этом вы будете писать меньше кода, более мощного с отдачей. Set(atom, value), Execute Task — гораздо более простые концепции для управления, чем диспетчеризация, действия, редукторы, саги и т. д.
Я создал репозиторий, чтобы подчеркнуть разницу.
Кривая обучения
Высоко в 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, который используется для отображения загрузчика до получения данных. Также для асинхронной операции мы можем использовать селекторы, которые очень надежны.
Запоминается
Кэширование можно выполнить с помощью библиотеки re-select для состояния Redux, Reselect кэширует вывод по сравнению с предоставленным ему вводом. Если у нас есть функция добавления, и мы вызываем ее с параметром 3,5, она вернет 8. В следующий раз, если вы вызовете ту же функцию с 3,5, она не будет повторно вычислять значение, она вернет кешированное значение, которое обрабатывается внутри в отдаче. Для этого вам не нужны никакие сторонние библиотеки.
В нашем репозитории, когда мы пытаемся вызвать API из асинхронного селектора, он вызывает только первый смонтированный компонент, позже он возвращает кешированное значение.
Заключение
Отдача все еще находится в экспериментальной стадии, и мы можем отслеживать ее здесь. В то время как Redux является очень стабильным состоянием. Принимая во внимание, что экспериментальная фаза все еще используется многими разработчиками, а также Facebook в производстве, я думаю, что она может заменить. Что вы думаете? Пожалуйста, поделитесь своими мыслями через комментарии.
Полезные ссылки
1. Репозиторий
