DevGang
Авторизоваться

Redux против Recoil: что  использовать?

Facebook недавно объявил о новой библиотеке управления состоянием для React под названием Recoil. Несмотря на то, что он все еще находится на ранней стадии эксперимента, он получил много ажиотажа с 8000+ звезд на Github.

Поскольку Redux является самой популярной библиотекой управления состояниями, используемой для React, естественно захотеть провести сравнение с Recoil - когда имеет смысл использовать одну над другой?

Store vs Atom

В Redux у нас есть концепция централизованного хранилища, в котором хранятся все данные для нашего приложения.

В простом примере списка дел ваш store будет выглядеть примерно так:

{
    listName: 'My cool to-do list',
    tasks: {
        '1': {
            name: 'My first task',
        }
    }
}

Вместо этого Recoil разделяет ваше состояние на отдельные атомы. У вас будет один атом для listName, а другой для tasks. Вот как вы можете создать atom для своих задач (взяты из документации Recoil):

const todoListState = atom({
    key: 'todoListState',
    default: [],
});

Пока я смотрел это видео ReactEurope, создатель Recoil, Дейв МакКейб, также представил возможность создания отдельных атомов для каждого из ваших элементов:

export const itemWithId =
    memoize(id => atom({
        key: `item${id}`,
        default: {...},
    }));

В нашем случае это будет включать создание отдельных атомов для каждого из tasks.

Что делает Recoil более производительным?

Дейв МакКейб упомянул в комментарии на HackerNews :

«Ну, я знаю, что на одном инструменте мы увидели примерно 20-кратное ускорение по сравнению с использованием Redux. Это потому, что Redux - это O(n) в том смысле, что он должен спрашивать каждый подключенный компонент о необходимости повторной визуализации, тогда как мы можем быть O(1). "

Отдача может быть O(1), потому что при редактировании данных, хранящихся в атоме, только компоненты, подписанные на этот атом, должны будут повторно визуализироваться.

В нашем примере списка дел, если бы у нас было 20 отдельных задач, у нас было бы 20 отдельных атомов. Если мы отредактируем пятое задание, только пятое задание нужно будет перерисовать.

Redux это позволяет достичь того же эффекта с помощью селекторов:

// selector
const taskSelector = (id) => state.tasks[id];

// component code
const task = useSelector(taskSelector(id));

Таким образом, компоненту необходимо будет выполнить повторную визуализацию только при повторной визуализации конкретной задачи.

Предостережение заключается в том, что каждый раз, когда изменяется какая-либо часть состояния, нашему taskSelector придется пересчитывать себя.

Мы также можем использовать оптимизацию, например createSelector, для сокращения дорогостоящих вычислений, но для этого еще нужно проверить, нужно ли сначала пересчитывать.

Я думаю, что эти оптимизации производительности означают, что Recoil может иметь смысл для огромных приложений, которые должны отображать большое количество компонентов на странице. Ваше обычное приложение, вероятно, будет хорошо работать с Redux, и я не думаю, что стоит переходить на Recoil только из-за потенциальных (возможно, несуществующих) преимуществ производительности.

Могут быть и другие причины, по которым вы можете перейти на Recoil - возможно, если вы считаете, что API имеет для вас больше смысла, чем Redux, или его проще использовать и понимать. Поскольку Recoil все еще находится в экспериментальной фазе, нужно будет подождать, чтобы увидеть, есть ли другие веские причины для перехода с Redux на Recoil.

Источник:

#React
Комментарии
Чтобы оставить комментарий, необходимо авторизоваться

Присоединяйся в тусовку

Поделитесь своим опытом, расскажите о новом инструменте, библиотеке или фреймворке. Для этого не обязательно становится постоянным автором.

Попробовать

В этом месте могла бы быть ваша реклама

Разместить рекламу