Тут вообще разницы нет

Просто у тебя данные будут разделены

Кэш react query будет хранить данные с сервака

А если я не хочу рендерить, а хочу дамп?

Не совсем тебя понял

Ну не хочу я рендерить, хочу слепок состояния сериализовать и положить куда-то. SSR или краш-репорт, например

Ну у тебя ж есть доступ к стейту и к кэшу. Делай с ним чо хочешь

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

Вот скину суть статьи

There are various categories of state, but every type of state can fall into one of two buckets:

1. Server Cache - State that's actually stored on the server and we store in the client for quick-access (like user data).

2. UI State - State that's only useful in the UI for controlling the interactive parts of our app (like modal isOpen state).

We make a mistake when we combine the two. Server cache has inherently different problems from UI state and therefore needs to be managed differently. If you embrace the fact that what you have is not actually state at all but is instead a cache of state, then you can start thinking about it correctly and therefore managing it correctly.

Я к тому, что состояние приложения — это композиция состояния ui и состояния «кеша».

Как jsx — композиция поведения и представления. Типа, можно отдельно писать html-шаблон и отдельно js. Как-будто separation of concerns. А можно объединить html и js в jsx. И тогда separation of concerns будет не в синтетическом разделении языков, а в органическом разделении компонентов.

Не в синтетическом разделении «логик», а в органическом разделении фич

это немного другое. С кэшем ты обращаешься иначе, чем с UI стейтом. Тебе не нужны асинхронные экшоны, оптимистик юай, инвалидация когда тебе нужно например хранить стейт того, открыт ли сайдбар

There are various categories of state, but every type of state can fall into one of two buckets:

1. Server Cache - State that's actually stored on the server and we store in the client for quick-access (like user data).

2. UI State - State that's only useful in the UI for controlling the interactive parts of our app (like modal isOpen state).

We make a mistake when we combine the two. Server cache has inherently different problems from UI state and therefore needs to be managed differently. If you embrace the fact that what you have is not actually state at all but is instead a cache of state, then you can start thinking about it correctly and therefore managing it correctly.

Интересно, в какой bucket попадёт состояние фильтра/сортировки абстрактного списка?

В стейт UI

кэш это как слайс данных с бэка

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

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

В случае с UI стейтом ты бог и царь

а кэш требует кучи дополнительных штук

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

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