Переделал вот так и с useQuery, спасибо. Так лучше)

Хорошо (-:

всем привет! Кто-нибудь использует Union типы для кастомных результатов вместо выбрасывания исключений?

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

Есть такая задачка. Функция регистрации возвращает либо true, либо объект с массивом ошибок. Я сделал union тип Boolean | CustomErrorsResult, но прикол в том, что у Boolean нету typename, и вообще мы не можем использовать скалярные типы в Unions. Получается нужно или наш boolean завернуть в BooleanResult и сделать объектом, но это уже оверкилл, либо возвращать только CustomErrorsResult, причем изменить его на CustomResult, в котором кроме поля errors[] будет поле ok: boolean.

Или оно того не стоит вообще? отказаться от unions и просто бросать исключения везде и всюду, даже на бизнес ошибки?

@nodkz дядь Паш, есть мысли?

Можно просто оставить errors: [CustomError!]!. Если фронту удобно ещё ok: Boolean! иметь, то вычислять его как пустой ли массив errors.

Из своей практики - юнионами не очень удобно.

Возвращай RegisterPayload с полями
ok: Boolean!
errorMsg: String
errorCode: String или Enum

Плюс если не боишься 4го аргумента в резолвере. То если поля ошибки запросили в запросе, то ошибку возвращаешь в ResultPayload.

А если запросили только поле ok, то в резолвепе в случае ошибки выкидываешь исключение. Чтоб ошибка вывалилась на самом верхнем уровне в errors.

Т.е. если клиент просит вернуть ошибку в пейлоаде, он ее там получает. А если не просит, то на верхнем уровне. Получается, что клиент через запрос управляет тем, как вернуть ошибку.

errorMsg: String не удобно, если ошибки в нескольких полях.

🖤

Возвращай массив. Тут нет универсального решения. Надо исходить из задачи и из удобства пользования.

@nodkz подскажите ещё пожалуйста такую вещь. Apollo Client всегда хочет id, чтобы стор нормализовать. Мне эти объекты ошибок при инициализации приложения сразу создать с айдишниками? А то получается неудобно, что каждый раз одна и та же ошибка прилетает с новым ID. Начинают в хранилище копиться

Id для чего-то кроме entity это мягко странно.

Без id крэшится стор :(

Нормализация нужна для обновления данных. Ошибки же никак не обноаляются.

Так сказать, каждый раз новые прилетают. Хоть и с одним и тем же текстом.

Аполло3?

Да-да

Я бы подождал еще месяцок

Это самый убогий баг у них сейчас