их на странице по цене и по алфавиту. Изначально добавил редьюсер SORT_BY_PRICE и SORT_BY_ALPHABET которые изменяли данные, которые пришли с бэка. Но мне сказали так неправильно менять данные, которые пришли из бэка, и сделать при помощи селекторов. Подскажите, в чем смысл?
потому что данные у тебя те же, ты просто показываешь их в разном порядке
посмотри за библиотеку reselect, в документации есть такой пример
олсо PRICE и ALPHABET
Хорошо, а если в сторе держать сортированный массив пицц это просто как бы получается нерационально, да?
не в сторе а в юз мемо
да. Если элементов ~100 то можно на лету сортировать, если больше, то отдельная ветка в сторе с сортированными айдишниками
Так а что лучше - useMemo или Reselect??
кiт или слон 🙂 это разные вещи. Плохо можно сделать с помощью обоих 🙂
понял, буду разбираться. Спасибо)
О, как раз дошёл до этой темы в обучении. Селекторы они как бы кэшируют подобные данные, так, что только при изменении фильтра будут обновляться. Если делать без селекторов, тогда при каждом обновлении будет перерендерится сортировка. Но вроде как там нужен и редюсер и селектор. Покрайнемере в курсе так делают вроде
Либо курс плохой, либо ты неправильно понял. Сами селекторы - это простые функции, которые ничего не кэшируют, а только производят выборку. Вызов таких селекторов происходит каждый раз, когда в редаксе диспатчится экшн, соответственно, если сортировать данные в селекторе, то на каждый диспатч будет происходить перерисовка компонента, в котором такой селектор подключен. Чтобы этого избежать, надо либо передавать второй параметр в useSelector, либо юзать reselect, второе предпочтительнее, т.к. при первом рендеров хоть и можно избежать, но сама функция селектора всё равно будет вызываться на каждый диспатч.
Я не знаю, что за курс, но не лучше ли передавать параметры сортировки на бек? Если, конечно, возможно.
Если у него в приложении не десятки тысяч пицц сортируются, то в этом нету смысла.
я про то и говорю, зачем ограничивать себя в ассортименте. по сложности одно и то же - что на фронте сделать, что на бэке, по факту - рендеру меньше работы, это всегда хорошо.
Ну да, давайте похерим перфоманс юзерам постоянными запросами на бэк, ради возможности оперировать числами, которые никогда не будут нужны. Надо адекватно подбирать решения под кейсы.
вкусовщина. по мне, так, если пользователей так много - это успех. если проект успешный - снимай хостинг жирнее. фронт не должен тормозить
Фронт как раз и будет тормозить из-за того, что сделать запрос к бэку занимает больше времени, чем сделать сортировку на клиенте в этом кейсе... Про хостинг пожирнее вообще без комментариев.
дебаунс и лоадер есть
И зачем это делать? Чтобы пользователя заставить лишнее время смотреть на вейтер, программистов писать и дебажить лишний код, а бизнес платить за лишние мощности?
Обсуждают сегодня