вот

Ну, значит надо смотреть какие необходимо указывать, и какие ты указываешь, и искать в чём разница

Всем доброго времени.

Завис с проблемой, а точнее с поиском ее решения.

Есть модель:
const schema = new Schema({
 user_id: {type: Types.ObjectId, ref:'User', required: true},
 year: {type: String},
 month: {type: String},
 graph: [{
     day: {type: String},
     shedule_id: {type: Types.ObjectId, ref:'Shedule'},
     state_id: {type: Types.ObjectId, ref:'State'},
 }],
},
{ timestamps: true }
)

Не могу правильно описать тип в GraphQL и мутацию добавления ,всего этого добра, в resolvers.

Заранее благодарен за ликбез и оказанную помощь.

Спасибо. Продолжаю экспериментировать. Решил свою проблему тут в onError плюс реактивные переменные.

ребят, кто-то сталкивался с такой ошибкой?

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

Можно установить приоритеты (fetchPolicy): 'cache-first' | 'network-only' | 'cache-only' | 'no-cache' | 'standby'

То есть поставишь fetchPolicy: 'network-only' и всегда будет летать запрос на сервер

Но я подмечу, что юзаю Apollo. Уверен есть то же самое и в Relay

у меня был прикол с cache-first что летело 2 запроса, но потом один cancel-ился, и в нетворке он был красным. Не думаю что это бест-практис... (тоже аполло юзаю)

Тут ещё такой момент, что скорее всего тебе не надо оба отправлять на сервер, если один свежее другого, второй просто возьмёт обновлённое из Кеша.

Но это мои догадки. Я такой же ещё профан в GraphQL .

угу, в теории всё так. На практике уже есть нюансы

Ещё момент, если это удобно, может есть смысл сделать просто refetch, там где это надо.

Например у меня есть компонент с комментом, где можно его лайкнуть.
Лайк у меня всегда летит на бэк. И в лайкХендлере я дергаю refetch коммента, что бы сразу отобразить изменение.

То в твоём случае, если у тебя один из запросов дергается позже, то можно перед ним сделать refetch.
Хотя мне кажется проще просто второй запросить сразу на бэк.

А лучше разобраться как запросить только кусочек запроса, используя фрагменты. Я пока не добрался до этого.

не совсем понял, зачем тебе refetch, но выглядит так будто ты пытаешься реализовать костылями то что предоставляется функционалом cache.modify -
https://www.apollographql.com/docs/react/caching/cache-interaction/#using-cachemodify

Вот я сюда сильно не заныривался ещё. Но как я понимаю это всего лишь модифицирует кеш.
То есть лайкнул пост запросом на сервер, а вместо того что бы обновить, меняешь локальное состояние.
А если за это время появились другие изменения в БД, то состояние компонента так и останется локальным.

Добрый вечер. Знакомлюсь с графом и есть гипотетический вопрос. Допустим у меня есть РЕСТ, который отдает жиииирные данные по эндпоинтам. Их немного, и каждый по каждой сущности отдает много данных. Можно ли юзать Граф подключаясь к эндпоинтам Реста, и формировать нужную выборку на этом уровне, а не к одному главному эндпоинту в классическом варианте?

Да, в резолвере вы можете использовать любые данные. У аполло даже есть: https://www.apollographql.com/docs/apollo-server/data/data-sources/

Ого. Спасибо. Я думал это мои бредовые идеи и спросил на удачу. Спасибо. Очень интересно!)

Здравствуйте. Снова вопрос. Из кэшированных данных полученных из Реста (memcached например) я тоже могу получать жирные данные для графа?

Всем ку, есть такой код
Как  я понял next срабатывает после каждого получения новых данных
Но вопрос в том что я не могу найти next в доке Apollo может кто-нибудь покажет где оно находиться вдруг там ещё куча полезных вещей есть