вуе что ли

хотя не

без всяких непонятных функций, которые делают какой-то эффект (actions.begin чет там)

Чем санк плох ?

без всяких непонятных функций, которые делают какой-то эффект (actions.begin чет там)

А я бы оба варианта хотел через. then

А я бы оба варианта хотел через. then

да речь там не про then/try, они изоморфны

а про begin/createTransaction

только бегин еще

а про begin/createTransaction

Ну я из c# не люблю эксепшены и много где их не рекомендуют создавать

так так и нет эксепшенов

Т.е.мне нравится твой вариант но только с вызовом кормит и реверт через then

ну так симпатичней

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

Да

ну так симпатичней

То что я и имел в виду, выглядит отлично

Кстати а смысл возвращаться пробинженый промис? Разве только функции комит и реверт не возвращают что-то?

но можно описывать такую логику

как higher order thunk

hot )

неееет

это тоже неверный термин, как и hoc

Выглядит немного костыльно на самом деле

(...args) сделай

ну я для санков юзаю ток 1 аргумент)

всегда, но суть в самом подходе

Есть ли смысл делать для остальных фич что-то в таком же духе как для транзакций в примере выше ?

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

но у меня вопрос, как это работает?

он же не может запоминать весь стор

ведь там между запросом и ответом еще что-то может происходить

Так должно быть?

да это же тупо пример, опечатка

вот если быть точным

Может я не шарю)

в редюсере есть 2 проперти, history, current

Вообще лучше сделать мидлвар тогда уж

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

Вообще лучше сделать мидлвар тогда уж

дык thunk это что)

Помимо его

когда ревертим с хистори берется этот обьект

типа для каждого запроса в хистори уникальный идентификатор, да?

А в чем прикол?

типа для каждого запроса в хистори уникальный идентификатор, да?

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

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

higher order *

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

Не очень понимаю зачем это нудно, если по сути транзакция - запрос который и так выполняет try / catch операции, т.е. Не меняет стейт до завершения, зачем для этого хистори?

Не очень понимаю зачем это нудно, если по сути транзакция - запрос который и так выполняет try / catch операции, т.е. Не меняет стейт до завершения, зачем для этого хистори?

ну транзакция на юайке это скорее optimistic апдейт

ты делаешь наперед апдейт, т.е begin показываешь какой-то стейт, а потом ждешь респонс

Понял

и если пришел еррор, то ты ревертишься к предыдущему стейту

Я обычно делал это в изолированном виде, не трогая основные данные

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

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

саги это вообще

http://www.usingcsp.com/cspbook.pdf

отсюда черапали идеи

А конкретно какой пример у данного кейса

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

корутины

А конкретно какой пример у данного кейса

Ну тут простой кейс, с оптмистик апдейтом

без лишнего бойлерплейта

Ну какие данные фигурируют

Тип сообщение в чат или ещё что

тудушка, сообщение в чат, загружающаяся картинка

да в принципе любое асинк действие

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

какой экшон вызывает begin? Откуда он берет данные?

а, current

но все равно, какой экшон?

какой экшон вызывает begin? Откуда он берет данные?

простыми словами, то type: {thunk.name+’:begin’}

Лучше сделать отдельный стейт, вот к примеру с редактированием объекта в большом списке твой вариант будет хорошо работать, а для сообщения в чате лучше сделать отдельный блок в котором отображается сообщение до того как будет получено с сервера

Лучше сделать отдельный стейт, вот к примеру с редактированием объекта в большом списке твой вариант будет хорошо работать, а для сообщения в чате лучше сделать отдельный блок в котором отображается сообщение до того как будет получено с сервера

видишь, тут надо что-то придумывать под кажый кейс

короче, вот контркейс

хотя это можно стандартализировать

отправляем второе сообщение, пока не отправилось первое

хобана

Ну тут дело в производительности скорее

отправляем второе сообщение, пока не отправилось первое

и ?

у меня у каждого санка в мету requestId)

в контексте

законтрил ?

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

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

пока размышляю над этим, но или уникальный айдишник, или что-то типа метода identify

который айдишник генерить с аргументов

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

Боксы помогут

В этом плане, доп стейт для асунк методов будет работать хорошо

Вообще я думаю это единственный правильный вариант

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

ну да выходит надо вертеться вокруг этого

или что-то с редюсерами мутить или еще что-то придумывать

Тип если есть стор сообщений, то у каждого сообщения может быть на пример дополнительный стейт который ещё не одобрен но отображается приориьетно

нужно хранить не данные, а миграции

в нашем случае это функция-ролбек