формально, да, StateUpdate == Pair
чет мне отдельный тип для такого больше понравился

но вопрос именно в том, как сформировать эффект на основании старого/нового состояния

глядя на conduitlurker, появилась такая мысль:
1. отдать в эффект предыдущее состояние и уже внутри чекнуть, удобвлетворяет ли этот массив условиям для расчета и сохранения
2. новое состояние сформировать просто через when с проверкой на достижение лимита - очистить, если привысили лимит, или продолжить наполнение

а как вы в ФП стиле (в стиле ли?) сайд-эффекты генерите?
ну, получается что-то вроде такого кода, но какой-то красивой возможности пропихнуть эффект, который основан на чем-то из нового состояния - невозможно.

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

Вот только прикол что основа фп была придумана до проблем)

Так это же и есть определение чистой функции

Так это же и есть определение чистой функции

Так речь идет не о функции, а о достаточно произвольном лексическом скоупе

Я тут, кстати, пока были обсуждения по мульти-ресиверам, придумал новое определение: на ряду с чистыми функциями, можно говорить о чистых скоупах. То есть тех, в которых есть изменяемое состояние, но так, что бы это состояние не убегало за предел скоупа. Инетересно, что -то такое формулировалось? Наверное да, ведь в реакте по сути оно и есть.

Во многих ЯП функция - единственный инструмент создания лексического скоупа

Так речь идет не о функции, а о достаточно произвольном лексическом скоупе

Но ведь это обыкновенная функция

Кстати, в Kotlin у тебя только функции и остаются

Вот не функция

Нет, еще есть скоуп класса

Нет, еще есть скоуп класса