Что можно, а что нельзя сохранять в redux store?

Question

[JS Noob]

Можно ли сохранять в store массив ссылок ref элементов react? Можно ли сохранить в redux store функцию, чтобы ее можно было доставать оттуда и подписывать или отписывать event listener'ами?

Comments

[Vann Damm]

всё что угодно можно. Другой вопрос принято ли？

[JS Noob]

effect_tw, у меня redux devtools через минуты три работы приложения отваливаются... Я вот не пойму, потому что я туда рефы записал или причина кроется в другом... Но рефы в девтулзах посмотреть нельзя, девтулзы жутко тупят, когда я в них открываю объект, где хранятся рефы...

Answer 1

[Klein Maximus]

Хранить можно все что угодно, в том числе ref-ы на элементы. Но нужно ли?

Comments

[JS Noob]

У меня из-за хранения рефов тормозят девтулзы. А через минуты три работы приложения они и вовсе крашатся (не уверен что из-за рефов).
Я хочу рефы хранить в сторе, чтобы сделать компоненты не связанными между собой. Можно конечно рендер пропсы юзать... Но я вот решил пойти по пути хранения в редаксе.

[Klein Maximus]

JS Noob, все же в хранилище редакса нужно хранить данные. Не понял на счет несвязанности компонентов, но мне кажется, у Вас что-то с архитектурой не то, раз нужно хранить рефы.

[JS Noob]

Klein Maximus, хранить рефы нужно, чтобы вешать на них обработчики событий...
Чтобы не быть голословным, вот код.
https://codesandbox.io/embed/one-button-test-ezp2c...

[Klein Maximus]

JS Noob, зачем это делать на рефах? Ведь событие как таковое может (и должно) отслеживать изменения в данных, и на них уже и реагировать.

[JS Noob]

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

[Klein Maximus]

JS Noob, в принципе, можно не хранить все рефы в сторе, а регистрировать только обработчик события onClick текущего активного элемента. Зачем там весь массив?

[JS Noob]

Klein Maximus, массив нужен, чтобы по индексу активного элемента получить onClick обработчик этого элемента. А как мне onClick по другому достать? Видимо я вас не понимаю...

[Klein Maximus]

JS Noob, когда элемент становится активным, просто сохранять сам обработчик в сторе, а не ссылку на элемент.

Вот накидал пример. Сделано на React Context, но это просто вопрос предпочтений. В компоненте Card я просто сохраняю onClick-обработчик (по сути, просто ссылку на функцию) текущего активного элемента в контексте (в Вашем случае это будет redux-store).

Никакой ref не нужен. Логика такова, что когда элемент становится активным, он сам сообщает контексту свой обработчик. И потом просто нужно подписаться на событие нажатия кнопки и запустить сохраненный обработчик события, что я и делаю в компоненте KeyDown.

Ну и регистрировать текущий обработчик можно не в самом компоненте карточки, а, например, прямо в списке. Тут опять же просто вопрос предпочтений.

[JS Noob]

Klein Maximus, воу, классно, спасибо, про такой вариант не подумал!
Но тут у меня возникает несколько других вопросов...
1) корректно ли хранить в сторе функции... собственно это и было частью топика : )
2) не является ли это менее производительным или более сложным? Ведь в случае с рефами я собираю все элементы и они хранятся статично в сторе. Далее я дёргаю стор только для изменения индекса активного элемента. А тут на каждый тик я перезаписываю и индекс и onClick...?

[Klein Maximus]

JS Noob,

корректно ли хранить в сторе функции

Почему бы не хранить в сторе функции? Функция - такой же тип данных, как число или строка. Хранится просто ссылка на область памяти, так же как и в случае с объектом/массивом.

не является ли это менее производительным или более сложным

На этот вопрос можно ответить только после замеров, но вряд ли. А на счет сложности... Ваш вариант намного сложнее.

Ведь в случае с рефами я собираю все элементы и они хранятся статично в сторе

Вы хотите "сделать компоненты не связанными между собой". Так в вашем случае компоненты становятся связанными с хранилищем. Т. е. если вдруг поменяется структура приложения, вложенность компонентов или изменится схема данных, то могут возникнуть проблемы. Вам придется менять код приложения. Когда глобально регистрируется только обработчик, то совершенно не важно, что-там может поменяться. Обработчик то регистрируется снаружи стора!

Далее я дёргаю стор только для изменения индекса активного элемента. А тут на каждый тик я перезаписываю и индекс и onClick...?

Вообще, хранение индекса активного элемента и хранение обработчика не связаны. По сути, хранимый индекс - это локальное значение, которое не используется за пределами компонента, который рендерит список. А вот обработчик события требуется.

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

[Klein Maximus]

JS Noob, вообще, не уверен, что в Вашем случае стоит регистрировать обработчик именно в сторе редакса. Сами данные элментов - да, подходит. Но вот регистрацию обработчика лучше отделить и разместить, например, в провайдере контекста реакта (как в моей реализации). Такое решение точно будет слабосвязанным.

[Klein Maximus]

JS Noob, если моя помощь оказалась полезной, отметьте, пожалуйста, мой ответ решением.

[JS Noob]

Klein Maximus, это я обязательно сделаю, просто пока мы были в стадии обсуждения я не отмечал. Огромное спасибо вам за вашу помощь!

Answer 2

[Frimko]

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

Answer 3

[bini1988]

https://redux.js.org/faq/organizing-state#can-i-pu...

Технически можно сохранить в redux store что угодно, это все ещё обычный js объект. На практике я бы избегал такого подхода, это скорей всего сломает devtools и потенциально приведёт к утечкам памяти.