Вот тут и стоит разделять глобальное состояние и кэш

Но если не использовать аполло как стм, то я бы посмотрел в сторону urql

Да разные могут быть комбинации. Чаще всего они обрабатывают разные данные, а где-то в апи слое их читают, склеивают и отправляют.
Лично я противник такого подхода

Ооо, погуглю, интересно

Это на словах хорошо звучит, а по факту это вообще не правильно готовят.
Если кеш менеджер выделять, то он должен быть на инфраструктурном/ системном (подставь свой базворд) слое приложения, а не в компоненте кверю фетчить. Я вообще ни от кого не слышу во фронте про выявление и разделение используемых моделей данных, хотя это должно быть стандартом в любой разработке софта

Тебе его уже советовали в другом чате))

Да, вспомнил, когда опять попал на этот сайт 😅
Незапоминающее название...

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

И без стм можно (нужно) апи-клиент выделять. Это зависит от конкретного разработчика

Если модели данных (клиента и сервера) идентичны, а точнее нет выделенной клиентской модели (нет редактирования данных или оно тривиальное), так можно делать. Но если на клиенте есть хранение (хотя бы сессионное) и редактирование каких-то немного специфичных от бека данных, то над моделью бекенда должна быть проксирующая абстракция, не дающая прямого доступа к модели бекенда, а лучше обобщающая ее.
Учитывая специфику юая, его контролов и среду его выполнения (и ее специфику, в плане каких-то невидимых состояний), описанный выше кейс встречается намного чаще чем может показаться

Type policies в аполло разве не решает эту проблему?

ну стм это очень узко, если учитывать перспективу когда стм будет вылезать на уровень взаимодействия с ресурсами бэка то почему бы не замахнуться на следующий уровень —  написать не просто стейт-менеджер а универсальную базу данных которая будет работать и на клиенте и на бэкенде и будет автоматически грузить данные из шаблонов (примерно как вот этот плагин к gql - https://babel-blade.netlify.app/docs/declarationdeclaration) но не только грузить а еще подписываться на оповещения всем этим данным в шаблоне а также автоматически в фоне синхронизировать изменения по данным (то есть как будто optimistic-ui только с выходом на offline-like синхронизацию). В итоге вообще не нужно будет разрабатывать отдельно бэкенд или api (фича автоматического бэкенда)  - разработчик пишет всю логику на фронте в одом месте (включая изменение данных) а бд на клиенте в фоне автоматически синхронизирует изменения с бд на сервере

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

Пописал доку для второго реатома: описал практически всю апишку, добавил сравнительную таблицу с другими СМ и еще по мелочи
https://github.com/artalar/reatom/tree/v2/packages/core

ВСЕ НА ОЧЕНЬ ПЛОХОМ АНГЛИЙСКОМ, пр велком на фиксы)

Супер! А по миграции есть что почитать?

Пока нет, но там не сильно сложно должно быть

сорь, не ПР:

https://github.com/artalar/reatom/tree/v2/packages/core#what-is-state-management
State is a term from FSA // FSM ?

https://github.com/artalar/reatom/tree/v2/packages/core#function-overloads
increment … increment ()
const add … increment() // add() ?
const set … increment() // set() ?

const counterAtom = declareAtom(($, state = 0) => {
  // the handler may be an action handler
  $(increment.handle(() => state++))
  return state
})

возвращаемое значение handle не используется же? Нам тут важно как-то подписать (`$`) declareAtom на increment action?

FSA // FSM одно и тоже


про increment не понял

const add = declareAction<number>()
increment(42)
// { type: 'action [2]', payload: 42 }

тут же должен быть вызов add а не increment