Thread by @jsunderhood

Итак, продолжаем про state management, а именно Apollo Client. apollographql.com/docs/react/

Для тех, кто не в курсе - Apollo Client это "толстый graphql-клиент". Он автоматически выполняет нормализацию кеша, пользуясь тем, что в GraphQL строго типизированные данные

О недостатках, хотя нет, хм... ОСОБЕННОСТЯХ Apollo Client можно говорить очень долго - к примеру, они КРАЙНЕ react-centric, но есть у Apollo Client важная фича - это управление local state

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

Почему почти? потому что придется писать директиву @client

@client Это звучит суперкруто - фактически мы получаем возможность спрятать от компонентов все за унифицированным ТИПИЗИРОВАННЫМ интерфейсом - graphql-запросами. Хотите - используйте это для локального состояния, хотите - чтобы реализовать допустим эндпойнт, которого на сервере ещё нет

@client К сожалению, именно что "звучит". Начнем с проблем:

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

Хотите какую-нибудь сложную логику а-ля redux-saga - пилите сами

@client Вы можете объявлять typeDefs для локального состояния, но они используются крайне ограниченно - не ожидайте что вас будут бить по рукам за нарушение типов схемы - к сожалению полноценная "проверка на соответствие схемы" слишком тяжела, чтобы жито во фронтенд-бандле

@client Вообще сам Apollo (здесь и далее я говорю о клиенте, если не сказано обратное) местами удивительно ограничен - к примеру если вы хотите после какой-то мутации ВСЕГДА выполнять какие-то действия - придется строить в Реакт свой хук (ав о вью всё еще хуже)

@client Да, в 2021 году от вас хотят реагировать на операцию изменения состояния на сервере в слое отображения. Есть альтернативы вида github.com/afafafafafaf/a… но они работают достаточно проблемно

@client Кроме того, local resolvers объявлены deprecated в текущей версии Apollo. Это удивительно, потому что предоставленный "альтернативный" механизм - type policies является, в отличие от local resolvers, СИНХРОННЫМ, а значит бесполезен чуть менее чем полностью

@client Моё удивление умножается на два, потому что local resolvers только только (две минорные версии назад, в 2.5) были приняты "в ядро", а до этого существовали как отдельный подпроект apollo-link-state.

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

@client В дополнение к этому, сама документация по управлению локальным состоянием в Аполло - гм.. по шкале 0..10 я бы оценил её на минус три. Почему так? Часть параметров упоминается только в API Reference, про то как взаимодействуют локальные резолверы и кеш почти не описано

@client Как следствие - когда я первый раз реализовывал простейшее локальное состояние - я сделал кальку с Redux по сути - так, к примеру мутации писали в кеш (который я использовал как стейт), но ничего не возвращали

@client Когда пришло прозрение (прямо посреди стрима), я переписал всю логику в более GraphQL-way и стало как минимум гибче - проявилась важная сторона локального стейта аполло - "плохой код" остается в рамках одного резолвера (так как резолверы между собой почти не взаимодействуют)