Так же флаг удаления

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

+геморно

ну че поделать

Я предложил вариант

флаг удаления для чего?

Я бы в этом случае просто кастомную вариацию для редюсера писал

вот мы изменили статус тудушки, куда там флаг?

под каждый кейс

Для того чтобы элемент не рендерился, вместо удаления или подмены стейта

Оптимизация

короче, есть вариант

это база данных как в Datomic

вот мой костыль)

когда мы храним массив патчей

я такую юзал на фронте (DataScript)

ролбек очень простой - тупо удаление одного патча

когда мы храним массив патчей

Там очень большое количество данных выходит

постепенно батчим их

оверхед из-за патчей

Можно жсон пачем хранить все изменения стейта)

Допустим есть сообщение, оно завернуто в { state:{}, asyncState:{ status:string, State:{}<}

Допустим есть сообщение, оно завернуто в { state:{}, asyncState:{ status:string, State:{}<}

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

хочется обобщенное решение

Это и есть обобщннное решение

Не нужно знать структуру стейта

так это и есть твое решение

Каждого элемента

у него state - current, asyncState - history

Достаточно знать структуру контейнера

у него state - current, asyncState - history

но этот варик нерабочий как оказалось )

ну да

Как я понял там был весь стейт

я короч подумаю над списком патчей

это единственный норм вариант имхо

ну да

а если сделать все редюсеры очень атомарными

с базовыми операциями

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

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

Вы там не гидхаб на режаксе решили написать надеюсь? ??

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

короч, у меня в голове дичайшная идея

пожоще тардиса

оверхед лютый

но рабочая вроде

буду ее думать

пожоще тардиса

ассоциация с доктором кто появилась)

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

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

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

хех

то есть брать данные из будущего и из прошлого

делал простой аналог такого на жс уже

типа замена каждого элемента массива на максимальный элемент этого массива за один проход

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

магия ленивых вычислений

т.е массив из геттеров ?)

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

в каком хачкеле, где все лениво, намного проще

У меня еще идея, если дифать стейт редюсера после каждого екшона

и заменять это на список json патчей

и потом когда захотим зареверить какое-то изменение, то надо лишь зареверить этот список

тут в чем проблема

долго

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

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

то есть это такой стэк из оптимистиков

*очередь

Блочить такие изменения

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

Велосипед выходит в любом случае

чет

то есть это такой стэк из оптимистиков

второй запрос выполняется (но begin проходит сразу) после того, как выполнится первый

Проще договориться с пмом что бы без этих оптимистиков

хддд

Ну оптимистик как правило нужен там где важна низкая задержка и маловероятно повторное взаимодействие с этим же элементом

Область применения все же нужно учитывать

ну возьмем тот же чат

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

Так это независимые элементы

Максимальная ошибка тут - неверный порядок

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

которые мне бы были крайне нежелательны

Вк говно

Мб не будем о плохом

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

Тут проблема уже в том что они хуево сделали

Это называется мы типа сделали, но работает 50 на 50

Как бы оптимистик но не факт что дошло

Много разных фич можно придумать, ту же серию, допустим отправленное сообщение ещё не подтвердил сервер, но пользователь отправил второе, ставим второе в очередь, но отображаем пользователю, готово, проблема вк решена

Теперь можно словить задержку серии сообщений, но они Хотя-бы будут соответствовать клиенту

Походу с оптимистик апдейтами единственно работающего решения нету

все это специфические кейсы

Ну сервер в любой момент может по какой-то причине абортнуть запрос, осталось просто рассмотреть все варианты возможных событий

Я бы даже сказал что их N кол., а значит вполне решаемо