Comments 9
Как-то совсем не упомянутый нативные useReducer в паре с useContext. В каких ситуациях они полноценно заменяют редакс, а в каких нет
Да вообще странная статья. Делить данные по частоте обновления? Orly? А по доменной принадлежности не лучше, не?
Например?
Например, какие-нибудь биржевые данные будут очень быстро меняющимися. Это не означает, что делая UI с графиками, воронками, и прочей инфографикой — их нужно растолкать по стейтам.
Те, кто их делает, просто смеются на подобные статьи. Порой приходится тупо EventEmitter использовать. А то и лучше rx-js, где уже все есть.
Скорее всего в вашем примере эти данные буду использоваться несколькими компонентами, поэтому применим другой критерий по частоте использования. Но что-то мне подсказывает, что в данном случае стоит использовать вообще что-то другое, чтобы сохранить производительность на приемлемом уровне, как, например, rx-js в каменте выше.
Первый критерий (частота изменения данных) выглядит очень сомнительным )) Допустим, есть где-нибудь какой-нибудь тоггл на странице, который пользователи тыкают один раз в пятьсот лет — что теперь, хранить его состояние в сторе? Куда более разумным кажется разделение по архитектурному слою. Например, данные пользователя — это слой бизнес-логики, и такие данные должны находиться в сторе (даже если они часто изменяются), а состояния UI компонентов — это UI слой и такие данные должны быть в стейте компонента.
А что, у вас тоггл переключает только своё собственное состояние, а в бизнес-логике никак не участвует? Какой-то странный тоггл.
Есть куча кейсов, когда тоггл отвечает за состояние UI, а не за бизнес-логику. Например, он закрывает/открывает какую-нибудь плашку. Или попап. Или тему с темной на светлую переключает (и хотя тему, скорее всего, мы не будем хранить в текущем компоненте, но все равно это пример UI данных, а не бизнес-данных). Именно об этом мой комментарий — не все данные есть бизнес-данные, во фронте есть куча UI данных.
Sign up to leave a comment.
Redux store vs React state