Pull to refresh

Comments 5

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

Дело в том, что мне года два назад пришлось из компонента прокидывать параметр в селектор таким образом, чтобы данные компонента аффектили результат. С разбегу параметризованный селектор провоцировал ререндер даже в случае идентичного примитивного целевого значения. Если не ошибаюсь, в самом селекторе обновлялась ссылка на него же. Точно не вспомню. Пришлось попотеть, чтобы решить проблему.

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

Спасибо за наводку) Интересный кейс, сам с таким не сталкивался. В будущем постараюсь разобрать его и, в случае чего, написать статью, так как действительно звучит как проблема, хоть и редкая, но необходимая к освещению

Как избежать ненужных ререндеров?

1) npm uninstall redux
2) npm i mobx

Спасибо, автор, за то, что осветил не такую уж и очевидную утечку производительности компонентов. Весь реакт основан на оптимизации перерендера, поэтому стоит учитывать материал статьи в проектированию кода реакт-компонентов.

Сам я исповедую идею "каждому используемому значению стора свой селектор". Для примера из статьи это выглядит так

// файл селекторов

export const counterSelector = (state) => state.counters;
export const firstCounterSelector = (state) => counterSelector(state).firstCounter;


// файл компонента
const firstCounter = useSelector(firstCounterSelector);

Мне не очень нравится идея вставлять везде shallowEqual. По крайней мере не стоит делать это бездумно.

Так же отмечу, что не всегда деструктуризация с useSelector'ом — зло. Очень часто ветки стора проектируются так, чтобы полностью использоваться в компонентах контейнера.

Например, так:
// компонент деструктурирует все значения объекта
const { isLoading, error, data } = useSelector(someDataSelector);


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

Рад, что моя статья вам понравилась, спасибо за добрые слова)

Насчет деструктуризации при использовании всего объекта. Да, вы в какой-то мере правы. Но я думаю, что в проекте лучше все держать в одних принципах и одном синтаксисе. Сейчас деструктуризация не мешает, а завтра надо будет отрефакторить или изменить логику и уже используется не весь объект и все равно менять использование.

Sign up to leave a comment.

Articles