a
Сделайте параметр мутации для типа статьи ENUM
Size: a a a
2019 January 14
a
Тогда будет ограниченный набор допустимых значений
EK
Закончил слайды к Питерскому митапу 24 января - Дизайн и паттерны проектирования GraphQL-схем
https://nodkz.github.io/conf-talks/talks/2019.01.24-piter-graphql-meetup/index.html
Чекните плиз на ошибки!
Это слайды к статье https://github.com/nodkz/conf-talks/tree/master/articles/graphql/schema-design
https://nodkz.github.io/conf-talks/talks/2019.01.24-piter-graphql-meetup/index.html
Чекните плиз на ошибки!
Это слайды к статье https://github.com/nodkz/conf-talks/tree/master/articles/graphql/schema-design
Пункт 6.4
Бывают случаи сложных мутаций, когда деление на разные мутации не выход, т.к. тогда будет лишнее копирование кода.
Ждем, когда завезут union инпуты, которые решат эту проблему.
https://github.com/facebook/graphql/issues/488
У мутаций должны быть четко описаны все обязательные аргументы, не должно быть вариантов либо-либо.Бывают случаи сложных мутаций, когда деление на разные мутации не выход, т.к. тогда будет лишнее копирование кода.
Ждем, когда завезут union инпуты, которые решат эту проблему.
https://github.com/facebook/graphql/issues/488
AB
Сделайте параметр мутации для типа статьи ENUM
Спасибо, попробую
a
Этот подход подойдёт при условии что типы статей у вас либо не меняются либо меняются очень редко
a
Если типы статей можно создавать через админку или ещё как, такой подход не подойдёт
DO
А подскажите момент с apollo-link-rest
Есть post->categories
как правильно сделать кучку запросов через @rest, чтобы получить массив категорий
не получается, пытается запросить
Есть post->categories
query {
post {
categories <-- вот тут массив id-шников
}как правильно сделать кучку запросов через @rest, чтобы получить массив категорий
categories
@export(as: "categoryId")
@rest(type: "Category", path: "/categories/:categoryId") {
id
name
}
не получается, пытается запросить
/categories/1,2,3 вместо waterfall'а запросов.DO
хотелось бы три запроса
/categories/1, ../2, ../3P@
Пункт
Мне не очень нравится идея добавления лишней вложенности (я про byPhone, byMail), тем более, что решить проблему обязательных полей можно другим способом.
Что, если сделать так:
type Claim, который имплементится типам ClaimByPhone, ClaimByMail.
В query использовать фрагменты. Получается строгая типизация без добавления лишней вложенности.
Прошу высказать ваше мнение, насколько плох/хорош предложенный мною вариант?
3.2. Группируйте взаимосвязанные поля вместе в новый output-типМне не очень нравится идея добавления лишней вложенности (я про byPhone, byMail), тем более, что решить проблему обязательных полей можно другим способом.
Что, если сделать так:
type Claim, который имплементится типам ClaimByPhone, ClaimByMail.
В query использовать фрагменты. Получается строгая типизация без добавления лишней вложенности.
Прошу высказать ваше мнение, насколько плох/хорош предложенный мною вариант?
Все правильно говоришь. И юнион тип тут как нельзя кстати будет.
Проблема в отсутствии хорошего примера для пункта 3.2. Все что не придумаю упирается в юнионы. А тут именно должен быть такой пример, который не позволит прикрутить юнионы.
Мне пока мозгу не хватает, что можно завернуть в качестве примера.
Проблема в отсутствии хорошего примера для пункта 3.2. Все что не придумаю упирается в юнионы. А тут именно должен быть такой пример, который не позволит прикрутить юнионы.
Мне пока мозгу не хватает, что можно завернуть в качестве примера.
P@
Пункт 6.4
Бывают случаи сложных мутаций, когда деление на разные мутации не выход, т.к. тогда будет лишнее копирование кода.
Ждем, когда завезут union инпуты, которые решат эту проблему.
https://github.com/facebook/graphql/issues/488
У мутаций должны быть четко описаны все обязательные аргументы, не должно быть вариантов либо-либо.Бывают случаи сложных мутаций, когда деление на разные мутации не выход, т.к. тогда будет лишнее копирование кода.
Ждем, когда завезут union инпуты, которые решат эту проблему.
https://github.com/facebook/graphql/issues/488
Пока живем без InputUnion желательно дробить (дублировать) для того чтобы на клиенте был статический анализ.
Проблема в том чтобы схема давала строгую типизацию, а не либо-либо. При либо-либо отлов ошибки происходит в рантайме. А здесь необходимо, чтобы на этапе разработки можно было ловить проблемы.
Проблема в том чтобы схема давала строгую типизацию, а не либо-либо. При либо-либо отлов ошибки происходит в рантайме. А здесь необходимо, чтобы на этапе разработки можно было ловить проблемы.
P@
@edk55 можем дискуссию в личку утащить по этим правилам, чтоб общий канал не засорять.
EA
У кого нибудь в Apollo server была проблема что у union типа не вызывается resolver с __resolveType?
EA
Сутки бьюсь
ИИ
там подсказки какие-то у меня были)
я по ним все сделал и было гуд
какая ошибка?
я по ним все сделал и было гуд
какая ошибка?
ИИ
он просит какой-то резолвер сделать,чтоб понимать какой тип отдается на выходе
a
У кого нибудь в Apollo server была проблема что у union типа не вызывается resolver с __resolveType?
When you have a field in your schema that returns a union or interface type, you will need to specify an extra __resolveType field in your resolver map, which tells the GraphQL executor which type the result is, out of the available options.
a
поможет?
EA
@akaSybe да по докам уже 100500 раз прошел, не понимаю что делаю не так
a
скинь пример куда-нибудь