да, я слышал этот аргумент, но все равно не до конца понимаю, чем это плохо? Если мы допустим выносим логику в отдельные чистые функции и используем их в кастомных хуках, то мы по сути так же отделяем логику от вью

я не набрасываю, просто хочу разобраться

нет, хуки это часть вью, и используются они только во вью слое

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

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


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

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

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

хм. а есть где то в опен сорсе пример проекта где логика полностью от вью отделена?

шо, по мобіксу глухо?

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

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

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

В общем я согласен что логику во вью лучше, но реакт квери не вынуждает тебя это делать.

Какая в итоге разница, достаешь ли ты перемапленные данные из стора эффектора или из кастомного хука

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

потому что нигде кроме вью(точнее реакта, sic!) - хуков нет, достаточно очевидно

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

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

насчет несложных проектов - как я сказал, может быть вполне ок

че значит "накрутить кеш"?)

накрутить либу для кеширования запросов

А отслеживание состояния + устареванип данных + дедубликация запросов. Дофига времени уйдет если все это накручивать

Если ты хранишь логику в отдельной функции которую вызываешь в useEffect, то какие проблемы просто вызвать ее в воркере

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

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

Можно. Но можно и просто запросить данные в несколько компонентов не заботясь о том, что они могут тригернуть несколько одинаковых реквестов

если честно, ни разу не сталкивался с такой проблемой

React query дает тебе прямой доступ к кэшу. Примерно как с редаксовским стором

но не дает даже базовых инструментов для работы с данными 🤷🏻‍♂️

весь датафлоу пишут кто во что горазд и как умеет

У меня был кастомный дропдаун который сам загружал данные, которые ему нужно показать. В связи с требованиями нужно было чтобы данные грузились сразу после рендера. Благодаря дедубликации отправлялся один запрос. Да, можно было отправлять один запрос из родительского компонента, но так дропдаун становился менее реюзабельным