Привет, чат! Может кто-то рассказать как решает проблему отстояной спецификации graphql

Question

Привет, чат! Может кто-то рассказать как решает проблему отстояной спецификации graphql

относительно nullability и undefinability полей?
https://github.com/graphql/graphql-spec/issues/476
https://github.com/graphql/graphql-spec/issues/542

Думаю, что в issue все можно прочитать, но кратко повторюсь тут.
Опциональность полей может означать:
* Что поле можно не передавать или обнулить его значение при помощи null
* Что поле можно не передавать, но нельзя обнулить
* Что поле должно быть обязательно передано, но может быть обнулено

Интересует полная картина решения проблемы как со стороны бэкенда, так и на фронтенде

#graphql #programming #russian

0

24.07.2021

3 ответов

14 просмотров

Александр Дербенёв Автор вопроса

Pavel @nodkz
> Опциональность полей может означать: > * Что пол...

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

0

04.10.2021

Pavel @nodkz

Александр Дербенёв
Вариант с дескрипшнами тоже рассматривал, но почем...

В любом случае, двигайтесь по пути наименьшего сопротивления и дайте бизнесу быстрое решение. Красоту нереально навести. И тем более я ещё никого не встречал, кто бы хорошее Графкуэль апи сделал с первой попытки. И даже со второй. Дзен приходит, где-то после 3ретей версии АПИ. Поэтому шибко не тормозите, пилите. Ведь у вас впереди еще столько рефакторингов 😈

0

04.10.2021

Pavel @nodkz · Accepted Answer

> Опциональность полей может означать: > * Что поле можно не передавать или обнулить его значение при помощи null > * Что поле можно не передавать, но нельзя обнулить > * Что поле должно быть обязательно передано, но может быть обнулено О хороший вопрос! У меня решается просто правилами, без директив и всяких или или – Если поле передано в переменных, то взять его значение и записать в базу. И все ньюансы уже закладывать в сами инпут типы. Для мутаций create - всегда явно помечать обязательные поля. Для update обязательные поля не помечать как NonNull, чтоб их можно было не передавать (не изменять). Если необходимо какие-то поля удалить, то заводим отдельную мутацию или отдельный аргумент, где явно передаем список полей на удаление. На практике, таких операци, где надо удалить поле у меня было очень мало. И просто обходились дополнительной мутацией. Я бы рекомендовал от общих кейсов перейти к конкретным, и вы увидите что это не настолько большая проблема. И 99% проектов с такой проблемой не сталкиваются, либо спокойно валидируются в рантайме, либо обходятся доп описанием в дискрипшене к мутации/аргументам. PS. Мир не идеален, но вы можете сделать идеальный дескрипшн для людей. И при небольшой сноровке, даже парсить эти дескрипшены на клиенте через интроспекцию. И тогда вам точно не нужны будут директивы. Накостыльте спецсимволы в описании 😉 Всяко лучше, чем в корне поля крутить как в аполо федерейшене.

169 похожих чатов

Привет, чат! Может кто-то рассказать как решает проблему отстояной спецификации graphql

3 ответов

Похожие вопросы