НО. Весторейт сейчас пилит opinionated mobx

https://github.com/mobxjs/mobx-state-tree

химера

И оно обратно совместимо с редаксом

Но да. В команде должно быть понимание архитектуры

Пользователь кликнул на кнопочку. Надо обновить пару сторов. Куда пихаете код, который за это отвечает?

Пользователь кликнул на кнопочку. Надо обновить пару сторов. Куда пихаете код, который за это отвечает?

В React-компонент, который вызывает два метода для каждого store

?

В React-компонент, который вызывает два метода для каждого store

То есть прям в реакт компонентах логика изменения сторов размазана тонким слоем?

Ну хочешь можешь создать третий сторе с одним методом ) имхо это лишнее

То есть прям в реакт компонентах логика изменения сторов размазана тонким слоем?

Нет, компонент ничего не знает о том, как работает стор

Нет, компонент ничего не знает о том, как работает стор

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

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

Компонент обновляет только те сторы которые использует

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

А ридакс компонент — что вызвать несколько экшенов.

Да, это норм, если свойство onClick знает какой метод обычно одного store вызвать, почему бы и не знать ему о двух

А ридакс компонент — что вызвать несколько экшенов.

Вообще-то нет. Ты диспатчишь один экшен, а дальше у тебя уже все инкапсулировано

А ридакс компонент — что вызвать несколько экшенов.

Можно диспатчить один экшн.

Если он знает как отобразить данные из сторов, то уж и запустить их обновление точно сможет, тем более если у него есть кнопка "Обновить"

Вообще-то нет. Ты диспатчишь один экшен, а дальше у тебя уже все инкапсулировано

Ну так и в сторе тоже всё инкапсулировано.

redux-act / redux-actions. Мне нравится первый, но должен быть хоть какой-то Свитчи — это издевательство, чесслово

AssignTo используешь?

AssignTo используешь?

По старинке руками?

что за AssignTo

что за AssignTo

Ну можно без дипатча экшн креатор вызывать

Но это сомнительно

Юзал redux-actions, но потом увидел кроч realt. Топчик.

Что только не придумают)

Слишком мало лайков

Для продакшна это недостаточный уровень хайпа

Но это сомнительно

Почему сомнительно?

За лайками не гнался

Прост по мне удобнее

https://github.com/almeynman/realt

оно? :)

?

Не, не то

realt.js.org

а выглядит как идеальная либа для редакса

Первое правило публикации в npm — проверить, сколько либ с таким же названием уже есть))

Первое правило публикации в npm — проверить, сколько либ с таким же названием уже есть))

это же старая шутка брать рандомное слово, добавлять react- и пить рюмку если если такое уже есть

Да да да))

Можно не добавлять react-

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

Можно не добавлять react-

ну с -react быстрее пьяным станешь

да просто уж пить тогда

?

пойду реально конька долбану

с этим дубаком простыть можно

да

Много у вас либ к ридаксу в проектах? Помимо байндингов к реакту? :3

это я про эти ваши реалты, ридакс-акты и прочее

как ты забыл про redux-form?

redux-act, redux-thunk, всё

redux-observable

https://github.com/mkamakura/redux-jquery

:trollface:

@dreamerinnoise думал щас бойлерплейта вывалят на 10 листов?)

@dreamerinnoise думал щас бойлерплейта вывалят на 10 листов?)

А то.

упс

Абрамов - это какой-то депутат? :)

Я выше картинки просматривал, случайно кликнул и она сама отправилась )

Абрамов - это какой-то депутат? :)

Самовыдвиженец от партии фейсбука

Почему сомнительно?

Ну у тебя есть экшн креаторы. Они создают экшены. Чистые функции, возращающие объектик. И тут бац и ты делаешь из них диспатчащие функции. Мне кажется это странным, не?

ERROR: S client not available

Причём мутабельно делаешь)

Причём мутабельно делаешь)

Ага

Ну у тебя есть экшн креаторы. Они создают экшены. Чистые функции, возращающие объектик. И тут бац и ты делаешь из них диспатчащие функции. Мне кажется это странным, не?

Ну я вроде не сталкивался с необходимостью использовать AC без диспатча. Так что почему бы и нет?

Я не то чтобы за такой подход. Просто интересно, какие подводные камни.

Я не то чтобы за такой подход. Просто интересно, какие подводные камни.

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

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

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

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

Ну из тупых компонентов я бы диспатчить не стал. А вот на счёт первого — аргумент.

Ну из тупых компонентов я бы диспатчить не стал. А вот на счёт первого — аргумент.

Ты бы не стал, а другие разработчики стали бы :)

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

это ложная логика какая-то если я в тупом компоненте пишу onClick={this.props.onClick}, какая разница, "диспатчащий" у меня экшн или проходящий через connect?!

компонент не меняется от этого

это ложная логика какая-то если я в тупом компоненте пишу onClick={this.props.onClick}, какая разница, "диспатчащий" у меня экшн или проходящий через connect?!

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

что значит "нет диспатча"

если есть диспатч значит компонент не тупой

что значит "нет диспатча"

Не очень понял вопрос. Откуда диспатч в тупом компоненте?

если есть диспатч значит компонент не тупой

+

тогда с точно такой же логикой мне никто не мешает в тупом компоненте сделать import { dispatch } from '../somewhere/store и написать onClick={dispatch(this.props.onClick())}

нахера только

никто

но если у тебя несколько сторов — уже не получится

одинаковых

тогда с точно такой же логикой мне никто не мешает в тупом компоненте сделать import { dispatch } from '../somewhere/store и написать onClick={dispatch(this.props.onClick())}

Никто не мешает, но это уже дичь же

вот именно

я с таким не сталкивался, но тем не менее

Почему вдруг эта дичь должна появиться после того, как кто-то assignTo сделает?

Почему вдруг эта дичь должна появиться после того, как кто-то assignTo сделает?

Появится не эта дичь. Просто повышает вероятность, что кто-то экшн дипачащий подрубит и дернет.

Вот глупости :)

надо архитектуру нормальную иметь, а не придерживаться низкоуровневого кода под предлогом "а иначе дичь начнётся" тогда уж все высокоуровневые языки — дичь )

я к слову не то чтобы за assignTo :) но аргументация против него такая мне не нравится

Соглашусь.

надо архитектуру нормальную иметь, а не придерживаться низкоуровневого кода под предлогом "а иначе дичь начнётся" тогда уж все высокоуровневые языки — дичь )

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