Как тру прогеры решают проблемы с ассинхронным обновлением setState ? Функция, которая вызывается после setState Дает старые данные.

не пытаются setState сделать синхронным)

а вот мне интересно, можно ли редьюсеры считать Dal уровнем с точки зрения архитектуры в общем ?

не пытаются setState сделать синхронным)

К примеру ?

Во всех приложениях больше хеллоуворлд

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

К примеру ?

componentDidUpdate к примеру; а зачем вообще че-то после setState писать

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

Ну это и есть размазывание

Ну это и есть размазывание

¯\_(ツ)_/¯

Привет. Кто работал с react-intl ? Как вывести сообщение в экшене или редьюсере. (без InjectIntl). Часть текста регулируется через экшены и редьюсеры, и нужно в них перевести

Только ты намертво ее привязал к стору. А я не хочу этого

Ну так редьюсер всегда работает со стейтом (не стором). Или как ты собираешься отвязать бизнес-логику редьюсера от стейта?

Привет. Кто работал с react-intl ? Как вывести сообщение в экшене или редьюсере. (без InjectIntl). Часть текста регулируется через экшены и редьюсеры, и нужно в них перевести

видимо если речь о коде вне реакта, то не нужен react-intl

Привет. Кто работал с react-intl ? Как вывести сообщение в экшене или редьюсере. (без InjectIntl). Часть текста регулируется через экшены и редьюсеры, и нужно в них перевести

что значит вывести сообщение в редьюсере или экшене?

Ну так редьюсер всегда работает со стейтом (не стором). Или как ты собираешься отвязать бизнес-логику редьюсера от стейта?

Я хочу чтобы стор занимался только одним — хранением данных.

Я хочу чтобы стор занимался только одним — хранением данных.

в том же редаксе так и есть, в чём проблема?

кто юзал react-final-forms? там можно в Field встаивть компонент не input типа и валидирвоать его?

посоны. Юзал кто линзы в редьюсере ?

componentDidUpdate к примеру; а зачем вообще че-то после setState писать

А можно ли повесить componentDidUpdate на 1 свойтсво стейта ?

что значит вывести сообщение в редьюсере или экшене?

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

А можно ли повесить componentDidUpdate на 1 свойтсво стейта ?

хах, нет, но можно использовать if

в том же редаксе так и есть, в чём проблема?

Ни в чем. Логику не хочу туда пихать

хах, нет, но можно использовать if

Что с чем сравнивать ?

видимо если речь о коде вне реакта, то не нужен react-intl

ну с двумя языками еще ладно, можно через тернар 2 разных сообщения вернуть. А если переводов будет 10?)

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

эм, словарик?

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

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

то есть логика пускай будет... в редьюсерах?)

Ни в чем. Логику не хочу туда пихать

Так редьюсер - это не стор. Это транзишн, а у транзишена, по определению, есть логика.

то есть логика пускай будет... в редьюсерах?)

Дебаунс событий там же?

Так редьюсер - это не стор. Это транзишн, а у транзишена, по определению, есть логика.

Хм. Асинхронные события туда же класть?

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

react-loadable например

Дебаунс событий там же?

дебаунс типа в миддлварах

дебаунс типа в миддлварах

Ага

Размазывание?

То есть размазали ровным слоем по всему коду

Согласен

Размазывание?

Именно!)

Интересно высока ли вероятность того что typescript умрёт в ближайшие лет 7

Интересно высока ли вероятность того что typescript умрёт в ближайшие лет 7

Нет

Интересно высока ли вероятность того что typescript умрёт в ближайшие лет 7

скорее чистый js умрет

скорее чистый js умрет

удоли

Интересно высока ли вероятность того что typescript умрёт в ближайшие лет 7

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

скорее чистый js умрет

Тоже очень вряд-ли

Именно!)

Мне вот удобный стор видится как некий объект, который имеет интерфейс очень похожий на лайфсайклы реакта в setState записываем состояние в didUpdate сайдэффекты с любой асинхронщиной

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

Не придёт.

Не придёт.

почему?

А почему? Был же Coffee, и что?

почему?

Потому что в рантайме она нахер не нужна.

А почему? Был же Coffee, и что?

не то же самое

Мне вот удобный стор видится как некий объект, который имеет интерфейс очень похожий на лайфсайклы реакта в setState записываем состояние в didUpdate сайдэффекты с любой асинхронщиной

Думал об этом. Не зашло. Я хочу открыть один файл и видеть весь бизнес-кейс

Думал об этом. Не зашло. Я хочу открыть один файл и видеть весь бизнес-кейс

хм, а в чём именно "не зашло"?

Ты хочешь просто "сверху вниз" писать логику со всякими кондишнл обращениями к серверу?

Думал об этом. Не зашло. Я хочу открыть один файл и видеть весь бизнес-кейс

для этого придумали сагу

хм, а в чём именно "не зашло"?

Оказалось больно бегать по методам класса. Да и выяснять куда что провалится. Порядок вызова и т.д.

Потому что в рантайме она нахер не нужна.

для оптимизации кода разве не лучше если код типизирован?

Ты хочешь просто "сверху вниз" писать логику со всякими кондишнл обращениями к серверу?

Ну почти

для этого придумали сагу

И все начали страдать))

И все начали страдать))

ой, прям))

ой, прям))

Я по крайней мере

Ну почти

Мне думается что это гиблая идея гнаться за такой целью Но конечно ты попробуй, посмотрим :)

для оптимизации кода разве не лучше если код типизирован?

Нет.

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

Мне думается что это гиблая идея гнаться за такой целью Но конечно ты попробуй, посмотрим :)

Уже прошел две итерации. Все больше нравится идея

И все начали страдать))

если сравнивать с thunk, то как раз меньше страданий

Мне думается что это гиблая идея гнаться за такой целью Но конечно ты попробуй, посмотрим :)

Цель немного не про линейность. А про сбор логики в одном меньше

если сравнивать с thunk, то как раз меньше страданий

Зато Санк гибкий. А сага костыль. Отлаживать его крайне больно

ERROR: S client not available

Зато Санк гибкий. А сага костыль. Отлаживать его крайне больно

потому что регенератор?

если сравнивать с thunk, то как раз меньше страданий

вот это ооочень спорно...

потому что регенератор?

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

Мне вот удобный стор видится как некий объект, который имеет интерфейс очень похожий на лайфсайклы реакта в setState записываем состояние в didUpdate сайдэффекты с любой асинхронщиной

Мне нравится интерфейс редакса: dispatch, getState, subscribe. От себя я только в интерфейс добавил memoize в своей библиотеке (вычисляет функцию только если стейт стора был изменён) https://github.com/blackakula/redux-composite

Мне нравится интерфейс редакса: dispatch, getState, subscribe. От себя я только в интерфейс добавил memoize в своей библиотеке (вычисляет функцию только если стейт стора был изменён) https://github.com/blackakula/redux-composite

Вообще-то функции должны именоваться в camelCase

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

Сага это не только и не столько про ожидание событий. Хотя, обычно когда заговариваешь про сагу, люди часто представляют её, как "штуку, которая умеет делать takeEvery". Ну и что-то нездоровое есть в той логике, в которой экшен, относящийся к одной фиче, тейкается в нескольких местах. Возможно, неправильно формализированы экшены. В принципе, согласен, нет технологии, гарантированно защищающей от спагетти в коде — было бы желание)

Сага это не только и не столько про ожидание событий. Хотя, обычно когда заговариваешь про сагу, люди часто представляют её, как "штуку, которая умеет делать takeEvery". Ну и что-то нездоровое есть в той логике, в которой экшен, относящийся к одной фиче, тейкается в нескольких местах. Возможно, неправильно формализированы экшены. В принципе, согласен, нет технологии, гарантированно защищающей от спагетти в коде — было бы желание)

Мне также не нравится, что сага крайне не явная

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

Open-Closed Principle - программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения. Как из своего модуля расширить систему, если нет возможности подписаться на события в сторе?

Мне нравится интерфейс редакса: dispatch, getState, subscribe. От себя я только в интерфейс добавил memoize в своей библиотеке (вычисляет функцию только если стейт стора был изменён) https://github.com/blackakula/redux-composite

зачем если есть reselect

?

Мне также не нравится, что сага крайне не явная

Значит, у тебя не было таких задач.

Open-Closed Principle - программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения. Как из своего модуля расширить систему, если нет возможности подписаться на события в сторе?

Составлять систему из модулей. А не расширять существующую

зачем если есть reselect

украл мой комент

Значит, у тебя не было таких задач.

Было. Решал проще. Переписал три проекта с саг. Один был прям большой

Значит, у тебя не было таких задач.

Давай пример задачи, где саги оправданны.

пойду я, ребят, поработаю. очередной сайдэффектосрач

зачем если есть reselect

логика reselect зависит от структуры стейта. Я как раз хотел избавиться от этой зависимости в своей либе

Давай пример задачи, где саги оправданны.

управление долгоживущим процессом

управление долгоживущим процессом

Это не задача

управление долгоживущим процессом

Ещё "логика на сайте" напиши. Поставь конкретную задачу.

управление долгоживущим процессом

(пишу)

Ещё "логика на сайте" напиши. Поставь конкретную задачу.

Запустил ты некий воркер, а воркер принимает кучу команд и выдаёт кучу событий, которые надо отображать в реалтайме. Например, воркером конкретно у меня служит бинарник mp3 плеера. Нужно запускать воспроизведение файла, отображать позицию, управлять позицией, управлять громкостью, реагировать на конец воспроизведения, и ещё огромная куча мелких задач. Я пробовал разные подходы, один раз даже полностью переписал логику с нуля, и сага в данном кейсе очень зашла. Мне удобно рассматривать саги, как аналоги unix-процессов, которые можно запускать, прерывать, форкать, джойнить итд.

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

так то сага для сайд эффектов больше

Запустил ты некий воркер, а воркер принимает кучу команд и выдаёт кучу событий, которые надо отображать в реалтайме. Например, воркером конкретно у меня служит бинарник mp3 плеера. Нужно запускать воспроизведение файла, отображать позицию, управлять позицией, управлять громкостью, реагировать на конец воспроизведения, и ещё огромная куча мелких задач. Я пробовал разные подходы, один раз даже полностью переписал логику с нуля, и сага в данном кейсе очень зашла. Мне удобно рассматривать саги, как аналоги unix-процессов, которые можно запускать, прерывать, форкать, джойнить итд.

Вообще не пойму как здесь Сага поможет. Обычный EE решает ситуацию на ура. Можно даже просто события в ридакс отправлять

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

Вообще не пойму как здесь Сага поможет. Обычный EE решает ситуацию на ура. Можно даже просто события в ридакс отправлять

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

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

Только вот отлаживать сагу боль. Так как линейности там нет на деле

Только вот отлаживать сагу боль. Так как линейности там нет на деле

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

Кто мучался с onseui ?

RouterNavigator - какую-то дичь предлагает в апи, а типы в ТС писали японские гомосеки к нему