https://redux-observable.js.org/

Что такое эпики?

Просто обычный стрим от redux экшна до другого redux экшна

миддлваря для редакса на основе RxJS, там эпик - RxJS стрим

В результате мы не пушим санки const ВЫПОЛНИСЬ_ПЛИЗ = (dispatch) => fetch(url) а создаём просто отдельный стрим, цепь событий которая последовательно выполняет все инструкции и ветвления после появления какого-либо экшна

Да, кнопкой спам тут ещё не спамили

с

Хм, совмещение RxJS с редаксом выглядит интересно

В результате мы не пушим санки const ВЫПОЛНИСЬ_ПЛИЗ = (dispatch) => fetch(url) а создаём просто отдельный стрим, цепь событий которая последовательно выполняет все инструкции и ветвления после появления какого-либо экшна

похоже на sage, где так же ожидается на вход какой-то экшн и дальше завертелось... разница толкьо в том что там на генераторах а тут на потоках

Да

похоже на sage, где так же ожидается на вход какой-то экшн и дальше завертелось... разница толкьо в том что там на генераторах а тут на потоках

я так понял из описания что это прямой аналог саги

Это саги аналог стримов)

ну не суть)

Разница в том, что на генераторах будет довольно фигово при ветвлении и объединении условий и потоков

Разница в том, что на генераторах будет довольно фигово при ветвлении и объединении условий и потоков

ну кто к чему привык... мне гораздо проще представить ветвление на генераторах

Вторую часть предложения потерял)

вторую часть не понял) приведи пример

Как в Реакте получить имя компонента?

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

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

Это для дебага нужно

displayName, component.constructor.name

Кстати о редаксе, а есть ли смысл дебаг-поля в сообщения включать? Типа откуда было послано сообщение и т.п.

displayName, component.constructor.name

А у Pure компонентов есть такая возможность?

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

Или ты каким тулом пользуешься которые строит граф тебе?

А у Pure компонентов есть такая возможность?

Смотря как ты их описываешь, думаю.

Хотя по идее доступно жолжно быть.

Смотря как ты их описываешь, думаю.

const a = () => (<p>test</p>)

А у Pure компонентов есть такая возможность?

Component.displayName || Component.name

@ZeroBias

Component.displayName || Component.name

А внутри компонента?

Внутри него самого

Внутри никак.

эм

лол

А лол

идите учить жс

Только если класс описываешь.

Зачем

я же и так знаю

идите учить жс

Скучно.

Понадобится - найду и запомню.

идите учить жс

иди учить албанский

Скучно.

Лол, с каких пор JS стал скучным? :)

Лол, с каких пор JS стал скучным? :)

Тоже верно) Однако нафиг учить то, что не надо.

@zuldare i mërzitshëm!

??

норм пацаны пишут вообще на clojurescript + om

так что нахуй этот ваш js

Ну бывает.

лучше на пурсе

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

Ну конечно эта проблема на уровень абстракции повыше всего этого) Но эпики работают таким образом, что экшн, на который они реагируют уже прошёл через redux state, так что можно при диспатче SELECT_SESSION показывать окно загрузки, а при завершении запроса — убирать. Стримы можно ветвить, const onlyNotFull = selectSession.filter( yourModel => !hasEveryField(yourModel)), поэтому можно не делать запросы когда не требуется

@ZeroBias интересно! А на медиуме, или где-то еще у вас под рукой есть статьи на эту тему???

Ну конечно эта проблема на уровень абстракции повыше всего этого) Но эпики работают таким образом, что экшн, на который они реагируют уже прошёл через redux state, так что можно при диспатче SELECT_SESSION показывать окно загрузки, а при завершении запроса — убирать. Стримы можно ветвить, const onlyNotFull = selectSession.filter( yourModel => !hasEveryField(yourModel)), поэтому можно не делать запросы когда не требуется

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

легкость внесение сайд эффектов это плохо (

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

Он не обладает сайд эффектами, иначе — ты просто неправильно его написал. В этом и расчёт

сайд эффекты же наоборот должны быть очевидны

Ну как ты берешь и ловишь токен

на выходе у тебя другой токен

и на этот другой токен подписывается разработчик 1

и разработчик 2

Мержа у них все ок

А на выходе фигня

ERROR: S client not available

Не понимаю тебя

.map метод должен безопасно возвращать объект, который принял из стрима

.filter туда же

В этой декларации, и в моём скрине выше просто не должно быть сайд эффектов по дефолту кроме заранее огороженных мест

я не про сайд эффекты

как функциональщину

а про то что не очевидно что продуцируемый токен

приводит к таким эффектам

Это проблема документации и структуры проекта

чуваки, кстати

а ни у кого нет линка на годный чатик по clojure?

upyachka.ru

онотоле одобряе?7?77??

ото

Это проблема документации и структуры проекта

Всмысле? (

Как ты структурируешь

и сколько у тебя народу в проекте

Блин, а как ты с обычными функциями живёшь, ведь их тоже кто угодно может дёрнуть?

И что нужно сделать с тем, кто дёрнул совсем не то

ну смотри я пишу тупой код. :( там он тупо последовательно выполняется. Все что он делает происходит внутри одной функции, другие функции он не трогает.

ну вот есть какой-то тулинг?

чтобы граф посмотреть

стримов

типа вот я вижу токен и хочу понять к каким эффектам он может привести

Стрим не создаётся из ниоткуда.

Ну конечно эта проблема на уровень абстракции повыше всего этого) Но эпики работают таким образом, что экшн, на который они реагируют уже прошёл через redux state, так что можно при диспатче SELECT_SESSION показывать окно загрузки, а при завершении запроса — убирать. Стримы можно ветвить, const onlyNotFull = selectSession.filter( yourModel => !hasEveryField(yourModel)), поэтому можно не делать запросы когда не требуется

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

Ну понятно что кто-то этот код написал и пишется он отлично удобно и красиво. Вопрос в его maintenance. То есть мне видя токен по этому коду не очевидно какие эффекты получатся в конце?

Как ты это все структурируешь так чтобы это было очевиднее?

Почему тебя это волнует? Тебе абсолютно не важно, откуда пришли данные к твоему условному стриму

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