a
mutation {
namespace {
doStuff1() {
id
}
doStuff2() {
id
},
}}
}
Size: a a a
2019 January 17
}
a
то последовательность не гарантируется
a
могу ошибаться
P@
В последнем случае не гарантируется
P@
Только тип мутации имеет такое правило на 1ом уровне
a
вот поэтому я и думаю, что можно указать в документе о дизайне схемы на эту особенность
a
чтобы потом те, кто посылают две вложенных мутации, не искали фантомный баг
P@
Обходится так
mutation {
M1: namespace {
doStuff1() {
id
}
}
M2: namespace {
doStuff2() {
id
}
}
}
mutation {
M1: namespace {
doStuff1() {
id
}
}
M2: namespace {
doStuff2() {
id
}
}
}
P@
Через алиасы
a
круто 👍
P@
Открой пжлста ишью, чтоб я не забыл этот пример в правила добавить
P@
Не за компом сейчас
P@
Но вообще две мутации в одном запросе большая редкость
P@
Но имеет право на жизнь
MM
как у вас тут дела с graphql?)
MM
что интересного произошло пока меня не было?)
a
я просто где-то на гитхабе видел что люди делают что-то типа:
mutation {
registerClient(...) { ... }
sendWelcomeEmail() { }
addBonusPoints() {}
}
mutation {
registerClient(...) { ... }
sendWelcomeEmail() { }
addBonusPoints() {}
}
a
я сам против такого подхода, но лучше предупредить тех, кто так делает
a
считаю что детали регистрации клиента должны управляться бизнес-логикой на бэке