-
Notifications
You must be signed in to change notification settings - Fork 52
Mutation chaining #41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Надо переспать с твоим предложением. На первый взгляд звучит очень круто! 👍 |
Я долго спал ))) Добрался до обновления правил, в виду подготовки к выступленияю с правилами v2 на РИТ++. В итоге, с первой частью твоего предложения я не согласен. 1) Можно попробоватьmutation {
post(id: 4) {
like { ... }
}
} При таком варианте
2) А что, если...
|
За эти 4 месяца попробовал это как-то использовать и пришел к выводу, что чейнинг мутаций - забавно, но они действительно больше путают, а самое главное - значительно усложняют запросы. При их использовании ломается правило "Один запрос - одна мутация" и во всех случаях , когда это правило хочется обойти, стоит просто сделать общую мутацию, так проще. В общем если и есть кейс, в котором эта "фича" может быть полезна, то его еще предстоит открыть :) |
Можно попробовать
В 6.1. объединять мутации не просто в namespace-типы, которые возвращают
{}
(что приводит к тому, что корень - пустой объект), а делегировать логику по "поиску" объекта, над которым будет произведена мутация, этому самому namespace-типу?То есть:
И, например, если поста с
id
4 не существует, то просто возвращаемnull
наpost
и на этом мутация завершится, избавив нас от потенциальных багов.А что, если...
Возвращать тот самый namespace тип в качестве поля результата мутации? Мы получим чейнинг :)
Таким образом мы можем проделать некие операции с только что созданной сущностью, не совершая лишних запросов с одной стороны и не плодить всевозвожные комбинации мутаций в схеме, тем самым делая её чище.
The text was updated successfully, but these errors were encountered: