Skip to content

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

Open
Donnyyyyy opened this issue Feb 12, 2019 · 3 comments
Open

Mutation chaining #41

Donnyyyyy opened this issue Feb 12, 2019 · 3 comments

Comments

@Donnyyyyy
Copy link

Можно попробовать

В 6.1. объединять мутации не просто в namespace-типы, которые возвращают {} (что приводит к тому, что корень - пустой объект), а делегировать логику по "поиску" объекта, над которым будет произведена мутация, этому самому namespace-типу?

То есть:

mutation {
  post(id: 4) {
    like { ... }
  }
}

И, например, если поста с id 4 не существует, то просто возвращаем null на post и на этом мутация завершится, избавив нас от потенциальных багов.

А что, если...

Возвращать тот самый namespace тип в качестве поля результата мутации? Мы получим чейнинг :)

mutation {
  post {
    create(...) {
      ...
      post { // Здесь мы имеем дело с только что созданным постом
        like { ... }
      }
    }
  }
}

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

@nodkz
Copy link
Owner

nodkz commented Feb 12, 2019

Надо переспать с твоим предложением. На первый взгляд звучит очень круто! 👍

@nodkz
Copy link
Owner

nodkz commented May 17, 2019

Я долго спал )))

Добрался до обновления правил, в виду подготовки к выступленияю с правилами v2 на РИТ++.

В итоге, с первой частью твоего предложения я не согласен.
Так бывает ;) Точнее их применить можно, но они больше запутают и принесут проблем в будущем.

1) Можно попробовать

mutation {
  post(id: 4) {
    like { ... }
  }
}

При таком варианте

  • сложнее писать резолверы для мутаций
  • мутация не может вернуть типизированную ошибку или статус (null обычно немногословен)
  • при ститчинге схем не будет работать

2) А что, если...

Возвращать тот самый namespace тип в качестве поля результата мутации? Мы получим чейнинг :) ввиду "забраковывания" первой части, это предложение уже выглядит не так шикарно. Но все еще здорово иметь чейнинг. Вобщем пока не ясно как с этим быть – пока не могу сформулировать хорошее правило и его рекомендовать. Так что пусть еще лежит ;)

@Donnyyyyy
Copy link
Author

Donnyyyyy commented Jul 25, 2019

За эти 4 месяца попробовал это как-то использовать и пришел к выводу, что чейнинг мутаций - забавно, но они действительно больше путают, а самое главное - значительно усложняют запросы.

При их использовании ломается правило "Один запрос - одна мутация" и во всех случаях , когда это правило хочется обойти, стоит просто сделать общую мутацию, так проще.

В общем если и есть кейс, в котором эта "фича" может быть полезна, то его еще предстоит открыть :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants