видел

В reducer не должно быть вычислений. Это тормозит весь flow redux.

какой флоу?

не хочу, спасибо

окей

чем хуев вариант с SomeService(state).doSomething()

где doSomething кинет action?

не хочу, спасибо

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

я понимаю

пытаюсь разобраться

без подъебов

сорян

чем хуев вариант с SomeService(state).doSomething()

разные подходы в идеале, твой сервис должен не зависеть ни от чего Типа MyService.action(data) -> resultData

какой флоу?

До окончания расчетов у вас встанет вся работа reducer-ов и последующих dispatch. Если вы делаете вычисления в actionCreator то вы не останавливаете redux flow

чем хуев вариант с SomeService(state).doSomething()

SomeService(store)

путаю термины постоянно

До окончания расчетов у вас встанет вся работа reducer-ов и последующих dispatch. Если вы делаете вычисления в actionCreator то вы не останавливаете redux flow

и что, что останавливаю?

окей data = SomeService.calculate(...) someAction(data)

так не?

окей data = SomeService.calculate(...) someAction(data)

я так и делаю)

ты прав в контексте если сервис в слое доменной логики лежит

окей data = SomeService.calculate(...) someAction(data)

ну как вариант это ООП-вэй с редуксом и миддлварами, без этого

и что, что останавливаю?

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

Где писать бизнес логику. Рассмотрим пример. Пользователь подвинул ползунок "сумма кредита" или ползунок "срок" - возникают соответсвующие Actions. Надо перемножить кучу коэффициентов, применить какие-то алгоритмы и выдать на экран "это вам будет стоить X% В функции actionCreator – 5 ??????? 42% В mapStateToProps/reselect – 5 ??????? 42% В обрабочике события внутри React компонента "ползунок" (или в одном из его родителей) – 2 ??? 17% Напишу специальный middleware ▫️ 0% В reducer (чистая функция вычисляющая новые X и Y) ▫️ 0% ? 12 people voted so far.

ну как вариант это ООП-вэй с редуксом и миддлварами, без этого

ну да, но вызов чего-то через. FUCJING_CONSTANT это как-то не ок

Petr добавь плиз мой вариант

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

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

а этого пока что задача не требует

data = SomeService.calculate(...); someAction(data)

Petr добавь плиз мой вариант

надо будет пересоздавать опрос

ну да, но вызов чего-то через. FUCJING_CONSTANT это как-то не ок

ну это уже на любителя но твой вариант мне нравится.

ну как вариант это ООП-вэй с редуксом и миддлварами, без этого

а что здесь оопшного, простите?)

А зачем ООПшить

Грубо говоря

Это какой-то ангуларвэй у Макса

Ну это ООП, да

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

Тики будут выделяться равномерно между actionCreator и другими действиями. Так вы остановите все обновления интерфейса связанного с redux.

точнее ДДД

да какое это ооп?)

вынос бизнес-логики в сервисы

Да не суть

Смысл?

Тики будут выделяться равномерно между actionCreator и другими действиями. Так вы остановите все обновления интерфейса связанного с redux.

да в любом случае остановлю

Смысл?

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

и не ддд это тем более

и не ддд это тем более

да ну?

ну да

пруф?

пруф на что? Где у вас границы аггрегата?

и не ддд это тем более

как раз таки ДДД (по крайней мере близко)

в ДДД можно без аггрегатов например

лол

убегаю, вечером продолжим )

окей, жизненный цикл вашей сущности есть или она умирает сразу после выполнения операции?)

хоть с кем-то за ддд попиздеть можно

Так я не понял, чем плоха схема — процессинг данных в экшене и диспатч готовых данных — редьюсер принимает данные и кладёт в стор

Так я не понял, чем плоха схема — процессинг данных в экшене и диспатч готовых данных — редьюсер принимает данные и кладёт в стор

мне ок такая схема, хз зачем новый слой хуярить

да нет плохих схем, но есть ситуации, где какие-то схемы не работают

мне ок такая схема, хз зачем новый слой хуярить

+

Процессинг можно в хелпер вынести

transformInputValues()/transformOutputValues()

Получает данные, возвращает данные

Самая большая проблема этих сервисов, это определение принадлежности Если А взаимодействует с Б, куда класть функцию? вот это бесит, поэтому лучше нах эти сервисы

Чистые функции, епта

Модель хранить как flow definition

Воткнуть babel-typecheck, чтобы в деве в рантайме падало

Ну и простой документ на который давно ссылаются, как acemarke, так и другие люди на рубеже redux: https://github.com/reactjs/redux/issues/1171

Что ещё нужно?

ERROR: S client not available

о декораторах интересная беседа завелась в бабель слаке

чуваки из в8 хотели попробовать заимплементить

оказалось, что в спеке есть не все необходимое

оказалось, что в спеке есть не все необходимое

а где почитать можно, чего не хватает?

https://babeljs.slack.com/archives/C062RC35M/p1490110695759930

https://babeljs.slack.com/archives/C062RC35M/p1490110695759930

спасибо

Ну и простой документ на который давно ссылаются, как acemarke, так и другие люди на рубеже redux: https://github.com/reactjs/redux/issues/1171

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

чуваки, а вот такой вопрос. У меня есть страница, на втором экране две половины. Клик в каждую переводит на свой роут, с анимацией. А именно половина раздвигается вбок, вниз, и превращается в страницу. Вопрос, как беспалева для пользователя первый экран выпилить из дома? то есть чтобы скролла не случилось при выкидывании его внаглую? отдельный вопрос в том, не перерисует ли мне роутер компонент, если там написано что по урлу / он отрисовывает Main, а по урлу /personal (левая половина например) он отрисовывает Personal

Самая большая проблема этих сервисов, это определение принадлежности Если А взаимодействует с Б, куда класть функцию? вот это бесит, поэтому лучше нах эти сервисы

Такая же проблема, к какому модулю отнести функцию

До окончания расчетов у вас встанет вся работа reducer-ов и последующих dispatch. Если вы делаете вычисления в actionCreator то вы не останавливаете redux flow

Не важно куда рассчёты положить: в actionCreator или в reducer или ещё куда - всё "встанет" одинаково, JavaScript однопоточный. Если расчёты занимают 1сек, например, то интерфейс "замёрзнет" на 1сек и в случае с actionCreator и в случае с reducer. Выбор того или иного места для запуска бизнес-логики не может быть аргументирован производительностью - она везде будет одинаковая, JavaScript везде одинаковый (пока не рассматриваем web workers)

Не важно куда рассчёты положить: в actionCreator или в reducer или ещё куда - всё "встанет" одинаково, JavaScript однопоточный. Если расчёты занимают 1сек, например, то интерфейс "замёрзнет" на 1сек и в случае с actionCreator и в случае с reducer. Выбор того или иного места для запуска бизнес-логики не может быть аргументирован производительностью - она везде будет одинаковая, JavaScript везде одинаковый (пока не рассматриваем web workers)

Да, я это писал, но более сжато)

Да, я это писал, но более сжато)

?

Не важно куда рассчёты положить: в actionCreator или в reducer или ещё куда - всё "встанет" одинаково, JavaScript однопоточный. Если расчёты занимают 1сек, например, то интерфейс "замёрзнет" на 1сек и в случае с actionCreator и в случае с reducer. Выбор того или иного места для запуска бизнес-логики не может быть аргументирован производительностью - она везде будет одинаковая, JavaScript везде одинаковый (пока не рассматриваем web workers)

Тут не производительность а организация кода

Кмк

Ну и простой документ на который давно ссылаются, как acemarke, так и другие люди на рубеже redux: https://github.com/reactjs/redux/issues/1171

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

Не важно куда рассчёты положить: в actionCreator или в reducer или ещё куда - всё "встанет" одинаково, JavaScript однопоточный. Если расчёты занимают 1сек, например, то интерфейс "замёрзнет" на 1сек и в случае с actionCreator и в случае с reducer. Выбор того или иного места для запуска бизнес-логики не может быть аргументирован производительностью - она везде будет одинаковая, JavaScript везде одинаковый (пока не рассматриваем web workers)

> Если расчёты занимают 1сек, например, то интерфейс "замёрзнет" на 1сек и в случае с actionCreator и в случае с reducer Нет

Расчёты можно разнести на несколько тиков и тогда у браузера будет время на интерфейс

А можно просто в воркер вынести

Давай подробнее

А то timeout ставить это как-то странно

чуваки, а вот такой вопрос. У меня есть страница, на втором экране две половины. Клик в каждую переводит на свой роут, с анимацией. А именно половина раздвигается вбок, вниз, и превращается в страницу. Вопрос, как беспалева для пользователя первый экран выпилить из дома? то есть чтобы скролла не случилось при выкидывании его внаглую? отдельный вопрос в том, не перерисует ли мне роутер компонент, если там написано что по урлу / он отрисовывает Main, а по урлу /personal (левая половина например) он отрисовывает Personal

хотя второй вопрос глупый, да. просто растяну половину на весь экран при componentWillUnmount, а потом новый компонент отрисуется новый, но который так же выглядит. Или мигнет?

А можно просто в воркер вынести

Ну это уже следующий шаг)

Ну это уже следующий шаг)

Да нет же, зачем заниматься разбиением по тикам?)

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

это ж какой-то ручной геморой

Да нет же, зачем заниматься разбиением по тикам?)

Ну если вычисления реально серьезные, то разница будет очень сильная

Ну это уже следующий шаг)

А анимацию вычислений поставить это какой шаг?

?

это ж какой-то ручной геморой

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

пока первые расчёты будут идти, пользователь ещё подвинет ползунок и что тогда? запускаем второй "процесс" рассчётов разбитый по тикам, а превый надо теперь как-то остановить... это целый свой планировщик!

А анимацию вычислений поставить это какой шаг?

Я имею ввиду следующий шаг если прям совсем уже тяжело считается

Давайте про воркеры подробнее