Я понимаю что это абстрактный пример, но в реальности 1) Отправлять значения инпута в стор на лету по умолчанию плохая идея 2) Подключать к стору 30 компонентов сразу(и все из них примонтированы в один момент времени) - очень плохая идея. На практике в один момент времени у тебя будут примонтированы 2-3, ну может 5 следящих за стором компонентов, поэтому импакт изменений довольно не значителен

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

Почему 1-пункт плохо? По второму: У тебя на странице минимум 20 товаров. Как ты будешь доставлять им данные?

Почему 1-пункт плохо? По второму: У тебя на странице минимум 20 товаров. Как ты будешь доставлять им данные?

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

Не рекомендую считать ваше видение архитектуры единственно верным.

По второму - через пропсы.

Это не мое виденье архитектуры. Это рекомендуемый метод использования редакса от авторов редакса. От того же Абрамова.

> Вообще библиотеки форм которые хранят данные напрямую в редаксе это зло Почему зло?

Таким образом, любое изменение стора тригерит всё через пропсы в низ по дереву

Потому что это медленно и не идиоматично. Локальный стейт компонента должен хранится в компоненте, а не в редакс сторе.

И?)

Ну. Если использовать библиотеку не так, как ее рекомендуют использовать - конечно будут проблемы.

Корневой вопрос. Почему это медлено?

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

Потому что обновление глобального стора медленней чем обновление локального стейта, как бы это ни было реализовано.

Фундаментальная ошибка в рассуждениях.

При любом обновлении стора нужно делать проверки "поменялись ли данные или нет".

Кто рекомендует? Абрамов не писал и не пишет на редаксе, а весь его опыт ограничен одной компанией.

Хмм. В чем?

поверхностное сравнение работает настолько быстро что это начнет иметь значение с десятков тысяч элементов

поверхностное сравнение работает настолько быстро что это начнет иметь значение с десятков тысяч элементов

Пары сотни на мобилке достаточно что бы это начало влиять на UX

Эм, да ну. DOM медленный, а мы DOM не трогаем. Сравнить пару сотен обьектов поменялись ли они или нет - занимает доли микросекунды даже на лоу-энд смартах.

Если бы это было так, то не появился тот же mobx.

Удивительно, но использование нового контекста негативно влияет на перф

Честно говоря с трудом представляю случаи когда это действительно важно. Медленно все что связано с DOM, остальные вещи обычно доли процента от производительности занимают.

Если это реально так не затратно, тогда откуда эти аргументы? https://t.me/react_js/757626

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

Что mobx, что реакт контекст используют для передачи данных, подозреваю что и reatom

Мы сейчас говорим вообще о разных вещах

?

Я не понимаю зачем такие вопросы спрашивать. Я не идиот вроде. Если есть какой-то поинт можно сразу его сказать

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

Reatom, Effector, MobX позволяют делать точечные апдейты и точечные подписки. Если кратко.

Вообщем народ, посмотрел я Мобкс вроде то что нужно, но есть странные моменты и не нравится форс декораторов, но мобкс похож на полюбившийся Vuex Посмотрел Redux, но меня смущает то что если хочешь дать доступ компоненту к стору то нужно писать mapState/DispatchToProps и коннектить + писать мешанину на экшн (мешанина = связка из константов + переброс этого всего в нужные свитчи)

Это старый пример явно. Открой офф документацию, там нигде декораторов нет.

Ладно, у меня лапки и я спать, я пытался

Народ, а что дает мне использование redux-thunk?

Подскажите, пожалуйста, в React предпочтительнее (в тренде) использовать компоненты-классы или компоненты-функции?

В официальной документации по redux-thunk куча примеров и подробно разобрано, если какой-то из них вы не понимаете, давайте о нем и поговорим.

все, перечитал там очень хорошо по английски описано, прошу прощения и спасибо)

Подскажите, можно ли одновременно запустить 2+ функции? У меня есть 2+ клавиши и каждая привязана к определенному звуку.

Вопрос, прощу поделиться опытом) Нормально ли это ! не разделять роутера на приложение а роутеры разделять на уровне компонентов. То есть умя есть формируется контент ивзависимости это для админа или для пользователя! И в самых далеких потомкой будет вот такое let User_or_Admin = (props) => ( <Switch> <Route path="/" exact component={() => <Info {...props} />} /> <Route path="/admin" component={() => <EditAdmin {...props} />} /> </Switch> )

всмысле

Хочу написать пианино

а так просто на каждую клавишу функцию, которая принимает индекс/key по которому запускаешь аудио

Хочу написать пианино

Вопрос, прощу поделиться опытом) Нормально ли это ! не разделять роутера на приложение а роутеры разделять на уровне компонентов. То есть умя есть формируется контент ивзависимости это для админа или для пользователя! И в самых далеких потомкой будет вот такое let User_or_Admin = (props) => ( <Switch> <Route path="/" exact component={() => <Info {...props} />} /> <Route path="/admin" component={() => <EditAdmin {...props} />} /> </Switch> )