мобиксовые

не совсем понимаю, как это и зачем. это всё же о разном вещи. оно больше именно для запросиков по сети / куда-то ещё

в теории, конечно, ты можешь сделать кверю к своему стору

хотя по идее getTodos что угодно может делать

тогда оно будет кешировано, да

но не будет реактивности (в плане - изменилось в сторе, нужно обновить и в кеше)

но на практике, реакт-квери позволяет писать 90+% логики вообще без стейт-менеджеров

раз 50 можно.

интеракция с мобиксом у нас прям в узких кейсах, где нужна логика на самом клиенте, которая выходит за рамки взаимодействия с бэкендом. т.е. управление UI, логика типа undo /retry (если это клиентский анду / ретри, если серверный, то и через react-query можно)


по факту ведь большая часть логики на фронте крутится вокруг "пошёл в бэк - взял данные - вернул - обработал" (если говорить о среднестатистическом проекте, аля админка или клиент социалки какой-то)

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

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

получается весьма удобно

вообще в целом такую историю можно и без привязки к реакту соорудить, просто каждый реквест в сторе оборачивать в track<T>, который либо выполнит запрос, либо возьмёт из кеша

всё-таки фетчинг хочется держать в сторах

можно, но у реакт-квери тонна возможностей, поэтому задолбёшься сооружать )

напр для актуализации данных можно настроить рефетчинг по потере / активации фокуса в окне

почему после Linq, Task string?

типа, юзер ушёл с вкладки, вернулся - реакт квери послал запрос и обновил кеш

какойто код невалидной

незнал что так можно