Comments 38
Я конечно извиняюсь, что высказываю впечатление, случайно зайдя в тему, не являясь реакт- разработчиком, но если фреймворк приходится использовать с такой гигантской инвалидной каляской, вы уверены, что это вообще можно называть фреймворком?
UFO just landed and posted this here
Действительно, сам по себе React фреймворком не является. Технически, это библиотека для создания пользовательских интерфейсов. Но за время своего существования эта либа обросла достаточно большой экосистемой с внушительным набором лучших практик и инструментов, что позволяет работать со всем этим как с фреймворком.
Примерно понял. Интересно про Redux с т.з. пользы и вреда. На счет того, что он дает удобство сопровождения понятно. А стор же отжирает память? Есть, скажем, таблица транзакций слева в 100 000 записей под гиг, которую хочет быстро проскролить аудитор, а справа форма с данными по выделенной транзакции. Если данные из выделенной строки перекидывать в форму не напрямую, а через стор, он же будет содержать дубликаты данных, которые уже находится в DOM-объекте HTMLTableElement.table.rows, да? Т.е. памяти страница отожрет в 2 раза больше как минимум. Еще наверняка есть какие-то обертки для каждой строки, которые слушают изменения в сторе, если данные транзакции поменялась из формы. Плюс журналируются изменные стэйты — еще минус память. Или все не так плохо с этой технологией, как кажется? Ну это так :)
Да, конечно будет кучу памяти отжирать. Но гигабайт данных отправлять в браузер одним куском, без пагинации? Тут у JS начнутся проблемы, не только у редакса. Это особенный случай, и решение понадобится тоже особое.
> таблица транзакций слева в 100 000 записей под гиг, которую хочет быстро проскролить аудитор
Если честно, не уверен, что это получится быстро даже на голом DOM. Обычно, когда работают с настолько большими датасетами, используют виртуализацию (react-virtualized, react-window).
> Т.е. памяти страница отожрет в 2 раза больше как минимум
Отожрёт если с прозрачностью ссылок что-то пойдёт не так, и только на отображаемую сущность.
> Еще наверняка есть какие-то обертки для каждой строки, которые слушают изменения в сторе
Нету. Стор модифицируется запуском редьюсера в ответ на action, который прокинули в систему (да, тут нюанс — запустятся все редьюсеры, если говорить о классических редьюсерах на switch/case). Дальше работает shallow comparison (проверяется ссылочная эквивалентность данных), чтобы избежать лишних ре-рендеров.
> Плюс журналируются изменные стэйты
Журналируются только action (обычный JS объект со строковым свойством type и вашей информацией), и только когда был подключён Redux Dev Tools или схожий middleware.
UPD: redux, кстати, только хранит данные, а уж как их отображать — не его задача. Вы можете работать хоть с VanillaJS и использовать redux, главное — подписаться на стор и адекватно реагировать на его изменения.
Если честно, не уверен, что это получится быстро даже на голом DOM. Обычно, когда работают с настолько большими датасетами, используют виртуализацию (react-virtualized, react-window).
> Т.е. памяти страница отожрет в 2 раза больше как минимум
Отожрёт если с прозрачностью ссылок что-то пойдёт не так, и только на отображаемую сущность.
> Еще наверняка есть какие-то обертки для каждой строки, которые слушают изменения в сторе
Нету. Стор модифицируется запуском редьюсера в ответ на action, который прокинули в систему (да, тут нюанс — запустятся все редьюсеры, если говорить о классических редьюсерах на switch/case). Дальше работает shallow comparison (проверяется ссылочная эквивалентность данных), чтобы избежать лишних ре-рендеров.
> Плюс журналируются изменные стэйты
Журналируются только action (обычный JS объект со строковым свойством type и вашей информацией), и только когда был подключён Redux Dev Tools или схожий middleware.
UPD: redux, кстати, только хранит данные, а уж как их отображать — не его задача. Вы можете работать хоть с VanillaJS и использовать redux, главное — подписаться на стор и адекватно реагировать на его изменения.
гигантской инвалидной каляской
интересно, чем обусловлено такое мнение?
Можно получить все тоже самое и даже больше(!) за 2КБ. Вот небольшой пруф
Ментейнеры Redux определённо проделали хорошую работу над ошибками. Всегда причислял к проблемам Редакса нечитабельное обновление вложенных объектов и сложности с типизацией. Наконец-то это дошло и до ментейнеров. Однако в Redux есть проблемы, не решаемые by design:
1) Необходимость держать стейт в нормализованном виде из-за иммутабельности. Иммутабельное обновление данных подразумевает, что все вложенные объекты тоже должны быть скопированы, что будет триггерить перерисовку компонентов, данные в которых остались по факту теми же. Об этом написано в документации. Проблема решается нормализацией данных, что только добавляет головной боли — придётся нормализовывать данные с бекенда перед вставкой в стор и денормализовывать обратно перед отправкой на сервер. Получается ORM на фронте, с Mobx это не нужно.
2) Для мемоизации нужно писать селекторы с ручным указанием зависимостей. Допустим у вас есть страница с товарами и кнопка «Load more», которая запрашивает товары с сервера пачками по N штук. Кнопка должна пропасть, если страниц с товарами больше нет. Это произойдёт когда количество загруженных товаров на странице станет равно общему количеству товаров на бекенде.
Код на reselect будет выглядеть так:
Код на Mobx будет выглядеть так:
Не нравятся декораторы — используйте функции. Декораторы inject и observer больше не нужны с выходом хуков. Mobx будет автоматически пересчитывать значение isLastPage когда хотя бы одна из зависимостей (products или totalCount) изменится.
Вычисления в селекторах на практике оказываются более сложными — например таблица с множественными аггрегациями по определённым полям и строкам. В таких случаях пересчитывания на каждый рендер компонента могут ухудшить UX. Для этих целей придумали мемоизацию и в Redux это делается очень многословно.
1) Необходимость держать стейт в нормализованном виде из-за иммутабельности. Иммутабельное обновление данных подразумевает, что все вложенные объекты тоже должны быть скопированы, что будет триггерить перерисовку компонентов, данные в которых остались по факту теми же. Об этом написано в документации. Проблема решается нормализацией данных, что только добавляет головной боли — придётся нормализовывать данные с бекенда перед вставкой в стор и денормализовывать обратно перед отправкой на сервер. Получается ORM на фронте, с Mobx это не нужно.
2) Для мемоизации нужно писать селекторы с ручным указанием зависимостей. Допустим у вас есть страница с товарами и кнопка «Load more», которая запрашивает товары с сервера пачками по N штук. Кнопка должна пропасть, если страниц с товарами больше нет. Это произойдёт когда количество загруженных товаров на странице станет равно общему количеству товаров на бекенде.
Код на reselect будет выглядеть так:
export const getProductPage = (state: RootState) => state.productPage;
export const isLastPage = createSelector(
createSelector(getProductPage, page => page.products),
createSelector(getProductPage, page => page.totalCount),
(products, totalCount) => products.length === totalCount
);
Код на Mobx будет выглядеть так:
@computed get isLastPage() {
return this.products.length === this.totalCount;
}
Не нравятся декораторы — используйте функции. Декораторы inject и observer больше не нужны с выходом хуков. Mobx будет автоматически пересчитывать значение isLastPage когда хотя бы одна из зависимостей (products или totalCount) изменится.
Вычисления в селекторах на практике оказываются более сложными — например таблица с множественными аггрегациями по определённым полям и строкам. В таких случаях пересчитывания на каждый рендер компонента могут ухудшить UX. Для этих целей придумали мемоизацию и в Redux это делается очень многословно.
Декораторы inject и observer больше не нужны с выходом хуков.
Страница, на которую вы дали ссылку, рассказывает только про inject, который в mobx-react изначально был пятым колесом в телеге. Декоратор observer всё ещё нужен.
Хук useObserver лучше не использовать в качестве основного решения. Даже там, куда вы дали ссылку, про него написано так:
Low level implementation used internally by observer HOC and Observer component.
И ещё вот так:
Despite using useObserver hook in the middle of the component, it will re-render a whole component on change of the observable. If you want to micro-manage renders, feel free to use <Observer />Despite using useObserver hook in the middle of the component, it will re-render a whole component on change of the observable.
Классовый компонент с декоратором observer будет работать так же — компонент будет полностью перерисовываться когда хотя бы одно из observable значений в render методе поменяется. Если хотим меньше перерисовок — либо разбиваем компонент на компоненты поменьше (тогда перерисовываться будут только дочерние), либо используем <Observer />. На практике мне всегда хватало первого варианта.
Декоратор observer всё ещё нужен.
Я не точно выразился. Имел в виду, что не обязательно прописывать experimentalDecorators в tsconfig, Mobx может использоваться и без декораторов:
export const Counter = observer(() => {
return (
<div>
<span>{counter.count}</span>
<button onClick={counter.inc}>Increment</button>
</div>
)
})
Работает так же, как и старый пример с декоратором:
@observer
export class Counter {
render() {
<div>
<span>{counter.count}</span>
<button onClick={counter.inc}>Increment</button>
</div>
}
}
Хуки же позволяют полностью переключиться с классовых компонентов на функциональные. Уже давно перестал использовать декораторы observer и inject, проблем в продакшене не было.
Если использовать хуки Redux получится лаконичнее:
import { useSelector } from 'react-redux';
const isLastPage = useSelector(
({ page }) => page.products.length === page.totalCount
);Идея в том, что селектор должен пересчитываться только тогда, когда поменяются переменные, на основе которых он считается — products и totalCount. В вашем примере это не соблюдается. Предлагаю более наглядный пример из документации Redux c зависимыми селекторами:
На Mobx это будет выглядеть так:
Мало того, что пример на Mobx объективно меньше и проще, так он ещё удобнее для рефакторинга — зависимости селектора не нужно прописывать вручную, а значит если нужно добавить ещё одну переменную на основе которой вычисляется значение, то мы добавим её в одном месте, а не в двух.
const getVisibilityFilter = state => state.visibilityFilter;
const getTodos = state => state.todos;
export const getVisibleTodos = createSelector(
[getVisibilityFilter, getTodos],
(visibilityFilter, todos) => {
switch (visibilityFilter) {
case 'SHOW_ALL':
return todos;
case 'SHOW_COMPLETED':
return todos.filter(t => t.completed);
case 'SHOW_ACTIVE':
return todos.filter(t => !t.completed);
}
}
);
const getKeyword = state => state.keyword;
const getVisibleTodosFilteredByKeyword = createSelector(
[getVisibleTodos, getKeyword],
(visibleTodos, keyword) =>
visibleTodos.filter(todo => todo.text.includes(keyword))
);
На Mobx это будет выглядеть так:
@computed get visibleTodos() {
switch (this.visibilityFilter) {
case 'SHOW_ALL':
return this.todos;
case 'SHOW_COMPLETED':
return this.todos.filter(t => t.completed);
case 'SHOW_ACTIVE':
return this.todos.filter(t => !t.completed);
}
}
@computed get visibleTodosFilteredByKeyword() {
return this.visibleTodos.filter(todo => todo.text.includes(this.keyword));
}
Мало того, что пример на Mobx объективно меньше и проще, так он ещё удобнее для рефакторинга — зависимости селектора не нужно прописывать вручную, а значит если нужно добавить ещё одну переменную на основе которой вычисляется значение, то мы добавим её в одном месте, а не в двух.
Господа минусующие, потрудитесь объяснить в чём я не прав. Ставить минусы исподтишка много ума не надо.
По-моему Ваши коментарии не связаны с темой статьи. За это вы и получаете минусы.
Да всё проще же. Просто кто-то с комментарием несогласен. Такое бывает с любыми комментариями. Но это не повод обвинять других пользователей в глупости.
Зачем приводить пример из mobx если статья рассказывает про инструмент для redux? Я вообще не увидел в статье использования селекторов. Есть упоминание что toolkit содержит реселект, но каждый может подключить любую другую библиотеку для создания селекторов, которая больше нравится.
Не вижу смысла в коментариях выше и в своих тоже. :)
Чтобы было с чем сравнить, разве нет?
Если бы статья называлась "Сравниваем mobx и redux", то да.
Если бы статья называлась "Сравниваем mobx и redux", то комментарий как раз был бы не нужен, сравнение было бы уже в статье.
То есть в статье автор рассматривает инструмент, который помогает разработчику redux, а комментатор приводит пример кода на mobx в котором без всяких инструментов можно получить хороший результат. Логично стремление автора коментария показать, что он умеет лучше. Но не логично что он делает это под статьей про инструмент, а не библиотеку полностью или же что-то похожее. За это он получил минус, это мое мнение, ваше мнение, что он получил минус потому что кто-то не согласен с ним, что вполне может быть. Предлагаю на этом закончить. С Новым Годом!
Как-то всё очень разрозненно в этих конструкторах на Redux, даже официальных. Те же селекторы болтаются отдельно, аналога React Dev Tools для них нет, хотя по сути это варианты представления Redux Store, семантически относятся к нему, так же как и мутаторы — что синхронные, что асинхронные. Популярность этой библиотеки крайне низкая, как для официальной — 2200 звёзд в Git. Можно сравнить с альтернативными, более комплексными решениями: Mobx, easy-peasy, overmind (на который перешёл codesandbox).
В react/redux стеке очень не хватает единообразия. Буквально на каждом уровне (компоненты/общий стор) по-своему организовывается кэширование и отслеживание изменений, а также хранение состояния и вычислимых свойств на его основе. Часто с помощью инородных сторонних библиотек типа reselect. Аналогично и для изменений — синхронные мутации встроены, асинхронные — через сторонние библиотеки вроде Thunk или Saga. Столько всего нагородили, а способа увидеть состояние приложения в целом — нет.
В react/redux стеке очень не хватает единообразия. Буквально на каждом уровне (компоненты/общий стор) по-своему организовывается кэширование и отслеживание изменений, а также хранение состояния и вычислимых свойств на его основе. Часто с помощью инородных сторонних библиотек типа reselect. Аналогично и для изменений — синхронные мутации встроены, асинхронные — через сторонние библиотеки вроде Thunk или Saga. Столько всего нагородили, а способа увидеть состояние приложения в целом — нет.
Redux DevTools способен обрабатывать модифицированный селекторами store, и выводить его в общем виде. А селекторы “болтаются отдельно”, потому что не являются часто используемой фичей.
Такое понятие “мутаторы” к Redux не относится.
Низкая популярность прежде всего связана с тем, что релиз библиотеки версии 1.0 состоялся всего 2 месяца назад.
Redux toolkit как раз и призван решить проблемы выбора подходящих средств из всего разнообразия в типичных случаях использования.
Такое понятие “мутаторы” к Redux не относится.
Низкая популярность прежде всего связана с тем, что релиз библиотеки версии 1.0 состоялся всего 2 месяца назад.
Redux toolkit как раз и призван решить проблемы выбора подходящих средств из всего разнообразия в типичных случаях использования.
Простите, как же селекторы не являются часто используемой фичей? Что вообще можно использовать вместо них, чтобы не повторять себя при сложных выборках из стора и чтобы мемоизировать выборки? Даже в самом этом Redux Toolkit встроена библиотека reselect. И селекторы не модифицируют стор вообще-то, идут отдельно от него, хотя логичнее, чтобы всё было в комплекте, как с геттерами в Vuex.
В большинстве случаев необходимо использовать прямую выборку из стэйта. Предпочтительное использование мемоизации заключается не в получении сложных выборок, а кэшировании комплексных, часто запрашиваемых данных в случае, если начинает провисать производительность. По поводу производительности и ее преждевременной оптимизации можно ознакомиться со следующей статьей: optimization guide.
Стор хранит нормализованные данные, данные можно нормализовывать как угодно до их попадания в стор. А после пользоваться ими как удобно. Селекторы модифицируют изъятые данные в конкретном месте, а Redux DevTools может это отображать как цельное состояние, это и имелось ввиду.
Это понятно, что мемоизация и сложные выборки — разные вещи, я же через «и» перечислил.
Стор хранит нормализованные данные, допустим, авторов и их книги с связями. Допустим, нам в разных компонентах надо считать число книг по авторам или выводить число книг, помеченных как новинка. Логично же сделать селектор, чтобы не повторять себя в каждом компоненте. Логично желание видеть значение этого селектора для отладки безотносительно того, в каком компоненте мы его используем. Это же свойство стора, одно из его расширенных представлений. Как view и процедуры в базе данных. Редьюсеры — как хранимые процедуры, меняющие стор. На данный момент не нашёл нормальных инструментов для решения этой задачи. Есть полузаброшенный проект для reselect, не позволяющий работать с большим числом селекторов, не выводящий их названия.
Стор хранит нормализованные данные, допустим, авторов и их книги с связями. Допустим, нам в разных компонентах надо считать число книг по авторам или выводить число книг, помеченных как новинка. Логично же сделать селектор, чтобы не повторять себя в каждом компоненте. Логично желание видеть значение этого селектора для отладки безотносительно того, в каком компоненте мы его используем. Это же свойство стора, одно из его расширенных представлений. Как view и процедуры в базе данных. Редьюсеры — как хранимые процедуры, меняющие стор. На данный момент не нашёл нормальных инструментов для решения этой задачи. Есть полузаброшенный проект для reselect, не позволяющий работать с большим числом селекторов, не выводящий их названия.
Логично желание видеть значение этого селектора для отладки безотносительно того, в каком компоненте мы его используем.
Последние версии Redux Devtools (2.15 точно) это позволяют.
Вы уверены? На данный момент селекторы — чужеродный для Redux элемент. Всё что я нашёл — вот это, где обсуждается необходимость данной фичи. Даже не представляю себе как бы Redux Devtools мог выводить информацию о селекторах без серьёзных изменений в способе их создания.
Привожу пример:
Селектор -
import { createSelector } from 'reselect';
const getNodes = (state) => state.nodes.data;
const treeNodesSelector = createSelector(
getNodes,
(nodes) => { ... Строится дерево из массива (добавляется поле children, к элементам)}
);
export default treeNodesSelector;MapStateToProps —
nodes: treeNodesSelector(state),Хранится в store в виде массива — data: [].
Результат в DevTools —
nodes: {
data: [
{
id: '1',
ip: '127.0.0.1',
name: 'What is Love?',
port: 1,
parent_id: null,
children: [
{
id: '6',
ip: '11.1.1.1',
name: '11',
port: 1,
parent_id: '1'
}
]
},...Всё правильно, но это React Dev Tools (я там в одном сообщении опечатался, имея в виду Redux Dev Tools). Это уже результат работы селекторов и просто свойства, переданные в конкретные React компоненты. В Redux Dev Tools только Redux state. Было бы удобнее видеть общую картину — состояние Redux state и всех зависимых от него селекторов, а не выискивать компоненты, где эти селекторы используются (они могут быть глубоко в дереве, генерироваться по условиям и т.д.), попутно бегая в код, чтобы смотреть какие селекторы в какие свойства мапятся.
Кроме того, селекторы позволяют абстрагироваться от внутренней организации стора, упрощая последующий рефакторинг. Тут неплохо описано. Поэтому любые решения, где они идут отдельно от стора и без возможности их удобного мониторинга, выглядят несколько куцыми.
Из статьи по вашей ссылке: you are not required to use selector functions in a Redux app, а также сказано “Similarly, you don't have to use the Reselect library to create selectors — you can just write plain functions if you want”
Не совсем понимаю. Разве это противоречит тому, что я написал выше? Разумеется, для простейших приложений, которые не будут развиваться и не потребуют рефакторинга, можно завязаться жёстко на структуру стора. Но разве это можно назвать хорошим стилем? Да и далее в статье «you are encouraged to use selector functions, and to use the Reselect library for memoized selectors» и сама вся статья об этом: «we recommend using selectors to encapsulate the knowledge of where a given piece of state lives. Ideally, only your reducer functions and selectors should know the exact state structure, so if you change where some state lives, you would only need to update those two pieces of logic.»
Ох блин, наконец дошло до людей что action+reducer+action creator это просто функция. Пройдет еще годик и дойдет, что можно дропнуть все эти велосипеды и писать старое доброе
export class ProductReleases extends Store {
productReleasesFetching(state) {
state.fetchingState = 'requesting';
}
productReleasesFetched(state, action) {
state.productReleases = action.payload.productReleases;
state.fetchingState = 'success';
}
productReleasesFetchingError(state, action) {
state.fetchingState = 'failed';
state.error = action.payload.error;
}
…
};с ровно тем же результатом
Доброго времени суток.
Подскажите пожалуйста касательно Redux Toolkit.
Мое приложение выводит список постов из группы vk.com. Сами данные получаю без пагинации, данных 30к+. Данные храню в редаксе в виде массива. Без использования toolkit при фетчинге наблюдались небольшие лаги, так как я в целом не делал никакой оптимизации.
Но после внедрения toolkit по данной статье начались сильные лаги при манипуляции со стором. В чем может быть причина и как это исправить?
Спасибо :)
Подскажите пожалуйста касательно Redux Toolkit.
Мое приложение выводит список постов из группы vk.com. Сами данные получаю без пагинации, данных 30к+. Данные храню в редаксе в виде массива. Без использования toolkit при фетчинге наблюдались небольшие лаги, так как я в целом не делал никакой оптимизации.
Но после внедрения toolkit по данной статье начались сильные лаги при манипуляции со стором. В чем может быть причина и как это исправить?
Спасибо :)
Sign up to leave a comment.
Redux Toolkit как средство эффективной Redux-разработки