DT
при чем тут интерфейсы?
Size: a a a
2019 November 22
KN
При том, что это нарушение SRP и не ложится на ISP
DT
не, ну можно разбить на несколько мутаций
YS
я бы сделал так:
и любое число параметров, которая либо ставит куку и отдает юзера либо отдает ошибку и все, дальше ходим в query { user { … } }
mutation signIn(email: String, login: String, password: String): User
и любое число параметров, которая либо ставит куку и отдает юзера либо отдает ошибку и все, дальше ходим в query { user { … } }
Я бы сделал Union на input типе и принимал бы либо токен, либо юзернейм с паролем, либо мыло с паролем
KN
т.е. метод должен отвечать за одно действие и не может менять логику налету, но при этом интерфейс описывает поведение этого объекта в целом
KN
а в языках без интерфейсов приняты подходы с утиной типизацией
KN
когда если что-то похоже на Х, то является этим Х
DT
вариант с интерфейсом выше решает твою проблему, не?
KN
Нет, я же про ISP говорил
KN
interface AuthenticatableByCredentials {}interface AuthenticatableByToken {}etc
KN
и у них разные методы
KN
вместо объекдинения всего возможного в одно большое и тяжёлое
DT
ну три варианта – это не много, и да, можно сделать три похожие мутации
KN
Не можно, а лучше.
KN
Потому что они могут идти через разные системы
DT
тем более ISP – это про ООП, а в слове graphql такой буквы нет
KN
Я три года назад зафорсил тему с ISP в Gql)))
KN
А сейчас уже в спеке возможность интерфейсам имплементировать другие интерфейсы
KN
Теперь форсю дженерики и алгебраические типы данных)))))