Это число постоянно меняется

В локальный стейт. Это немного сложнее реализовать, но он надёжнее.

По сути тебе надо будет сделать редакс для локального стейта.

А, что если это число понадобится чуть позже отображать в двух местах?

Ну, у меня обычно для запросов есть библиотечка, которой передаёшь колбеки для каждого события. Ты можешь передать методу 2 колбека, которые будут изменять локальный стейт.

Может в кейсе, где нужно отобразить число в двух местах, стоит уже хранить в редаксе?

Мне кажется так будет удобнее

Ну, я в редаксе храню реально глобальные вещи. Это инстансы библиотек и локализацию.

Просто если есть возможность хранить данные локально, то лучше их хранить локально, имхо.

Гемороя меньше будет.

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

Ребята кто в каком редакторе кода работает ?))

vim

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

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

Да дело даже не в сложности кейсов. Ты же сам должен понимать, какие данные application-wide, а какие component-wide

combineReducers для того и нужен чтоб глобальную дуру разобрать на кусочки

Вот скажем виджет, который показывает курс валют A -> B в банковском приложении. По кнопке он меняет на B -> A. Из стора он вытягивает сам курс, а вот направление - данные не приложения, его нужно хранить локально

combineReducers для того и нужен чтоб глобальную дуру разобрать на кусочки

Да, но это только маскировка проблемы. Тебе всё равно надо следить за этим состоянием. Может редьюсеры и стали меньше, но в общем это не поменяло ситуацию.

Как ты писал полные пути в состоянии: a.b.c.d.e, так и пишешь, как использовал глобальные имена type, так и используешь.

Как ты писал полные пути в состоянии: a.b.c.d.e, так и пишешь, как использовал глобальные имена type, так и используешь.

Не понятно. > полные пути mapStateToProps? > глобальные type А если нужно среагировать на экшен в нескольких местах?

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

если данные запрашиваются с сервера, а юзаются в одном месте, то все равно redux.

Не понятно. > полные пути mapStateToProps? > глобальные type А если нужно среагировать на экшен в нескольких местах?

Это другое дело. Да. В первоначальной задаче такого сценария не было.

Как ты писал полные пути в состоянии: a.b.c.d.e, так и пишешь, как использовал глобальные имена type, так и используешь.

Никто не мешает разбить экшены на 100 файлов, если нужно.

Я думаю что redux нужно использовать везде, где это не приводит к проблемам с производительностью

Ну, если его использовать везде, то там начинается ад с диспатчами.

Какой ад?

Ну, "везде" - это локальное состояние тоже хранить в редаксе?

если данные запрашиваются с сервера, а юзаются в одном месте, то все равно redux.

Ну если данные используются в одном месте и отображаются только один раз, то можно без редакса

Ну, "везде" - это локальное состояние тоже хранить в редаксе?

Почему бы и нет? Сейчас оно локальное, а через 3 месяца понадобится в другом месте.

Ну если данные используются в одном месте и отображаются только один раз, то можно без редакса

То есть ты хочешь сделать запрос на didMount, там же обрабатывать ошибку? Нее, если с сервера, то держи в редаксе, там еще и мидлвары полезные, без которых не обойтись

Я просто видел проект где для всех данных пришедших с сервера используется редакс

Могу скинуть

github: opendota ui

а почему бы не делать так?

Просто у меня в голове так: в редаксе нужно хранить данные, которые 1) затрагивают больше, чем 1 компонент 2) если изменение и чтение данных происходит в разных компонентах.

Ну иногда это слишком, для случаев когда данные используются в одном месте и отрисовываются они один раз

В остальных случаях я использую локальный стейт.

А работу с сервером лучше вынести в отдельную библиотеку и там с этим мучаться.

Просто у меня в голове так: в редаксе нужно хранить данные, которые 1) затрагивают больше, чем 1 компонент 2) если изменение и чтение данных происходит в разных компонентах.

ты тоже будешь фетчить в didMount, если юзается в одном месте?

ты тоже будешь фетчить в didMount, если юзается в одном месте?

Внешняя библиотека.

А работу с сервером лучше вынести в отдельную библиотеку и там с этим мучаться.

У меня так и сделано, но второй программист хочет писать вообще без редакса

И я хз, как его убедить или лучше согласиться с ним...

У меня так и сделано, но второй программист хочет писать вообще без редакса

Ну, я с помощью редакса подключаю библиотеки. Это очень удобно.

У меня есть LibsReducer, в котором я просто создаю инстансы библиотек.

Такой DI для бедных.

Типо паттерн Фабрика?

Типо паттерн Фабрика?

Возможно, я не особо ориентируюсь в них.

У меня есть LibsReducer, в котором я просто создаю инстансы библиотек.

Зачем?

Внешняя библиотека.

Да какая разница. То есть в компоненте A ты фетчишь вызывая экшен redux'а, а в компоненте B фетчишь прямо в didMount

А потом внезапно нужны данные компонента B в другом месте и ты переписываешь его как компонент A.

Тебе не кажется, что проще сразу сделать в едином стиле?

Зачем?

Чтобы везде использовать одну копию библиотеки.

отредактировал*

Ну, если понадобится внезапно, то можно после решить что делать.

Чтобы везде использовать одну копию библиотеки.

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

А решать сразу общую задачу - ну, это бесмысленно.

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

Дай ссылку, пожалуйста.

А так будет каша из двух разных подходов в проекте

Я за "единый стиль"

А потом внезапно нужны данные компонента B в другом месте и ты переписываешь его как компонент A.

Я стараюсь не делать преждевременной оптимизации. Когда нужно, тогда и делаю

Я за "единый стиль"

Я тоже

А решать сразу общую задачу - ну, это бесмысленно.

Все библиотеки сделаны чтобы решать общую задачу, лол.

Дай ссылку, пожалуйста.

Какую ссылку?) Инициализируешь либу и делаешь ей export

Тем более с крутыми мидлварами даже быстрее и проще выйдет

Все библиотеки сделаны чтобы решать общую задачу, лол.

Мои нет, мои решают мою задачу.

Но вряд-ли я смогу убедить второго разработчика

Но вряд-ли я смогу убедить второго разработчика

Скажи ему что он дурак и не лечится.

Какую ссылку?) Инициализируешь либу и делаешь ей export

Ну можно и так. Но мне не особо нравится это решение. Отторжение на уровне религии вызывает.

ERROR: S client not available

reducer - чистая функция, в которой не должно быть сайдэффектов. Делая там вещи типа "инициализация библиотек" ты это нарушаешь

Ребята кто в каком редакторе кода работает ?))

Webstorm

У меня так и сделано, но второй программист хочет писать вообще без редакса

«Пока хочет»

С редаксом я могу получить в редюсере данные, которые запрашиваю с сервера (или отсылаю) заранее для оптимистичных данных, а потом автоматически вызовется FAILURE в случае ошибке, где достану предыдущие данные, которые также автоматически сохраняются. Это позволяет писать оптимистичные изменения парой строк кода

Ну можно и так. Но мне не особо нравится это решение. Отторжение на уровне религии вызывает.

Понятно ?

Скажи ему что он дурак и не лечится.

Нельзя так

С редаксом я могу получить в редюсере данные, которые запрашиваю с сервера (или отсылаю) заранее для оптимистичных данных, а потом автоматически вызовется FAILURE в случае ошибке, где достану предыдущие данные, которые также автоматически сохраняются. Это позволяет писать оптимистичные изменения парой строк кода

Крут. Я стараюсь в редьюсере логику не писать. Для логики есть другие места.

Какую логику?

А вчера меня закидали помидорами, когда я призывал использовать для пришедших данных с сервера редакс

Хранить все в редаксе - тоже не абрамоугодно

ты что-то путаешь. В редюсере только сохранение оптимистичных данных на REQUEST, заменя на SUCCESS данными с сервера (там же id прилетает настоящий) и откат на FAILURE, никакой логики нету

это еще позволяет в мидлваре отслеживать ошибки и выводить нотификацию

ты что-то путаешь. В редюсере только сохранение оптимистичных данных на REQUEST, заменя на SUCCESS данными с сервера (там же id прилетает настоящий) и откат на FAILURE, никакой логики нету

Вполне возможно.

Ибо Абрамов говорил, что любой нормальный чел понимает, что есть данные приложения, а что есть данные компонента

И хранить все в редаксе - дибелизм

Это и перегрузка стора кучей хлама типа значения некого инпута в хрен пойми какой модалке, и куча диспатчей ненужных

Хочется редакс для компонента - есть же локальный редакс

Хочется редакс для компонента - есть же локальный редакс

Стейт?

Нет, recompose/withRedux

Ну вот, обеденное обсуждение. Аж приятно стало)

редакс - такая простая вещь, что реализовать его локально даже без рекомпоса - десяток строк

Вполне возможно.

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

редакс - такая простая вещь, что реализовать его локально даже без рекомпоса - десяток строк

А можно пример?

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

В таком сценарии да, твой подход оправдан.

У меня немного по другому. В библиотеку прокидывается колбек "что делать, если возникла ошибка". Туда я могу запихнуть всё что угодно.

Нет, recompose/withRedux

Пример вот этого)

Хоть алерт, хоть console.log, хоть сигнал редаксу.

recompose/withReducer.js at master · acdlite/recompose https://github.com/acdlite/recompose/blob/master/src/packages/recompose/withReducer.js

А, пример прямо в ридми

https://github.com/acdlite/recompose/blob/master/README.md#lift-state-into-functional-wrappers

Ага, спасибо