Комментарии 3
А мне крупно повезло что я не работаю с GraphQL. И кажеться уже никогда не буду работать.
Вставляю 5 копеек. Всё, кроме использования селекта, это нарушение архитектуры приложения. Данные должны преобразовываться в том же слое, где они были запрошены. Это не должен быть транспортный слой - он представляет нам только запрос на бек. Это не должен быть слой рендера - это не его задача трансформировать данные. А вот использование селекта это самый правильный путь. У нас есть точка входа для вызова и тут же точка выхода данных. Контроль осуществляется в единственном месте и не размазан по приложению - коллеги скажут вам спасибо, что не приходится искать места трансформации. Для лучшего контроля можно создать хук useTodoQuery и уже в него дополнительно передавать опции самой квери, конечно же опционально. Это даёт нам переиспольщуемый хук с возможностью контроля данных в месте использования.
Кажется, что этого практически не бывает, но при работе с публичными REST API в корпоративных приложениях такое случается.
Вот как раз в публичных API такое и случается только случайно, уж простите за тавтологию. Потому что оно и для вас, и для Пети, и для соседнего отдела, и для интеграции с другой компанией. GraphQL собственно для того и нужен, что бы дать возможность более гибко получать то что нужно всем заинтересованным. А вот что бы пготовить и отдавать ДТО, которое точно ложиться на ваш фронт используются подходы вроде BfF.
Преобразования данных React Query