Попиарюсь https://www.npmjs.com/package/redux-act-dispatch-free

мне не нравится

☹️

а, стоп, я смотрел на assignAll, мне он не нравится

а что делает твой модуль я пока не понял

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

а что делает твой модуль я пока не понял

хаах

нет, мне он просто не нравится, экшонКреаторы на то и экшонКреаторы, что чистые

а у тебя это сайд-эффект

Ты про мой или про артема ?

я как почти профессиональный хаскелист (в смысле работу на нем нашел, и приняли, но еще не писал ничего и не скоро буду), против сайдэффектов)

про Артема

Так а как еще делать сайд эффекты >_>

в занках. ассинхронный экшон-креатор с занками не делает сайд-эффекта, если что

Вот сейчас не понял. Мои createAsyncAction работают практически так же как санк

он создает объект (функцию), который его делает, то есть по сути описывает его, он все еще чистый

Глянь код, там 15 строчек или типа того

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

у меня в начале тоже так было assignAll(actions, store);

но потом я от этого отказался

И потом даже от своей мидлвары отказался)

лучшим решением для всего этого (в том числе я для тестирования) я нашел саги, саги абсолютно чистые

но я не хочу их поддерживать в проекте на кучу людей, где многие на все это плевать хотели

лучшим решением для всего этого (в том числе я для тестирования) я нашел саги, саги абсолютно чистые

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

Я не понял, что у меня не так

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

а еще типы

Я не понял, что у меня не так

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

Экшн через createAsyncAction выстреливает как обычный, просто по дороге уходит асинхронная функция в свободное плавание

Мой не делает

У меня этим мидлвара занята)

Или я не понимаю, опять же

немного не понял, он типа сам делает isFetcing?

я обьявляю екшоны вот так и потом возвращаю обернутые другой функцией екшоны

которая резолвит их если это промис и добавляет на промис функцию cancel еще

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

busy, success, cance, loading

еще не придумал как лучше сделать с мета параметрами

покажи пирмер экшона, не совсем понимаю что происходит

on - хендлит только success екшона auth, т.е когда auth зарезолвится, то туда пойдет пейлоад

если интересно, то могу оформить нормально https://github.com/zhDmitry/rrethunk

вообще идея и половина кода отсюдова сворована https://github.com/wellguimaraes/actionware

но мне не понравилась идея что там надо делать setStore(store)

И что экшоны это не совсем екшоны, а какие-то особенные функций которые не санк и не что-то еще

т.е. createReducer({}).on(actions.fetchData, (state, payload)=>{возвращает изменение стейта, вызывается при успешном экшене?}

правильно я понял?

да

Твой идентити нифига не идентити)

Это K*-комбинатор

у меня идея такая action => dispatch((state)=>({...state})) вызывается экшон, в котором содержится логика, та же асинхронная операция, экшон диспатчик универсальный экшон который содержит чистую функцию изменяющую стейт, по сути это выглядит как action(args); стейт изменился. По сути у меня вместо редьюсеров обрабатывающих экшены - экшены редьюсеры. Ограничений нет никаких, полная совместимость с redux.

у меня идея такая action => dispatch((state)=>({...state})) вызывается экшон, в котором содержится логика, та же асинхронная операция, экшон диспатчик универсальный экшон который содержит чистую функцию изменяющую стейт, по сути это выглядит как action(args); стейт изменился. По сути у меня вместо редьюсеров обрабатывающих экшены - экшены редьюсеры. Ограничений нет никаких, полная совместимость с redux.

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

на пример? полное логирование и возможность отправлять снапы экшенов

Ты немного совместил концепции которые не надо совмещать

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

да я понимаю, не понимаю почему это плохо

Есть асинхронный екшин, а есть парсер который меняет данные

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

Например зачем тебе в екшоне делать ({…state, …newState})

это должен делать редюсер, а не асинхронный екшон

или например у тебя на один асинхронный екшин подвязаны два редюсера

Один смотрит на данные, а второй на статус с которым зарезолвился екшон

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

У тебя в одном месте сошлить три разных действия

это нерпавильно

Сам апи запрос, парсинг данных и бизнес логика

почему? чем это плохо

Буковка S в слове Solid не зря есть

The Single Responsibility Principle

И это не только к классам применимо

Любой метод должен делать одно действие и не больше

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

Я вот так это организовал

конечно не все правильно сделано

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

а, т.е. мне лучше сделать отдельный файл или структуру в которой будут собраны методы работы с api?

Мне кажется, что да

S лучше понимать как "единственная причина для редактирования"

то есть "этот компонент/функцию/класс нужно редактировать только если нужно поменять верстку, а этот только если логику"

про api очень полезно сейчас было, даже не задумывался, потому что не дошёл ещё

то есть "этот компонент/функцию/класс нужно редактировать только если нужно поменять верстку, а этот только если логику"

Да, но и парсинг файлов и екшоны и апи это все логика, но мне кажется пихать их в одно место не лучшая идея

я только сейчас узнал, что thunk позволяет пропихивать что-то внутрь себя

типа третим аргументом

то есть "этот компонент/функцию/класс нужно редактировать только если нужно поменять верстку, а этот только если логику"

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

если делать все эффекты ТОЛЬКО в экшонах, то это вполне себе мини-DI, туда нужно весь api кидать

если делать все эффекты ТОЛЬКО в экшонах, то это вполне себе мини-DI, туда нужно весь api кидать

Я так и обхожусь пока.

в третий аргумент закинул обьект который возвращает мне всякие полезности или токен или квери парамсы или просто утиль функции для которых надо контекст

экшоны - это какое-то абстрактное действие, которое как-то меняет стор (или не меняет). Один экшон может менять стор во многих местах. Причем можно совсем в левом редьюсере подписаться на чужой экшон