fe
аполло странный
Мб)
Size: a a a
2020 March 14
fe
а если мы будем проверки писать не предмет ошибок, когда success true - это просто пустая и неэффективная трата времени
+
EL
нужно с бэком такое обсуждать
на бэке всегда может произойти что угодно, даже если вы всё обсудили и даже если он написал идеальный код. у тебя на фронте ВСЕГДА должна быть ветвь кода, которая показывает «невозможную» ошибку
GP
В смысле :)
а сорян, эт я про запросы graphQL
EL
а если мы будем проверки писать не предмет ошибок, когда success true - это просто пустая и неэффективная трата времени
ну в итоге ты не потратила время, а юзер страдает. довольна?
K
а если мы будем проверки писать не предмет ошибок, когда success true - это просто пустая и неэффективная трата времени
+
GP
там типа просто поле указал и все
ҪҸ
ну в итоге ты не потратила время, а юзер страдает. довольна?
что ты хотел в билле купить-то?
ҪҸ
гречи, туалетной бумаги и консервов?
EL
гречи, туалетной бумаги и консервов?
да. и антисептик
GP
на бэке всегда может произойти что угодно, даже если вы всё обсудили и даже если он написал идеальный код. у тебя на фронте ВСЕГДА должна быть ветвь кода, которая показывает «невозможную» ошибку
невоможную ошибку сложно показать без привязки к какому-то полю
а если оно может быть тогда каким угодно?)
а если оно может быть тогда каким угодно?)
EL
невоможную ошибку сложно показать без привязки к какому-то полю
а если оно может быть тогда каким угодно?)
а если оно может быть тогда каким угодно?)
если у тебя в ответе нет ни одного тру, то ты уходишь в ветку с невозможной ошибкой, что тут сложного?)
EL
привязываешься к полям смело
EL
это твоя работа
fe
на бэке всегда может произойти что угодно, даже если вы всё обсудили и даже если он написал идеальный код. у тебя на фронте ВСЕГДА должна быть ветвь кода, которая показывает «невозможную» ошибку
Может второй бэк на фронте писать
Что если ошибка бизнес-логики? Для юзера пришло скажем кол-во друзей слишком большое. На фронте историю запрашивать и кидать ошибку "ты не мог столько друзей за день набрать?"
Фронт верит бэку, это везде так принято
Ну, где бэк свой
Что если ошибка бизнес-логики? Для юзера пришло скажем кол-во друзей слишком большое. На фронте историю запрашивать и кидать ошибку "ты не мог столько друзей за день набрать?"
Фронт верит бэку, это везде так принято
Ну, где бэк свой
EL
Может второй бэк на фронте писать
Что если ошибка бизнес-логики? Для юзера пришло скажем кол-во друзей слишком большое. На фронте историю запрашивать и кидать ошибку "ты не мог столько друзей за день набрать?"
Фронт верит бэку, это везде так принято
Ну, где бэк свой
Что если ошибка бизнес-логики? Для юзера пришло скажем кол-во друзей слишком большое. На фронте историю запрашивать и кидать ошибку "ты не мог столько друзей за день набрать?"
Фронт верит бэку, это везде так принято
Ну, где бэк свой
чувак, ну юзеру поебать, что там у вас принято. он в итоге страдает
GP
ну если предположить что с бэка может прийти что угодно, там может тогда и стринг прийти пустой и еще хрен че пойми, или не пустой))
GP
потому договоренность лучше всего
EL
ну если предположить что с бэка может прийти что угодно, там может тогда и стринг прийти пустой и еще хрен че пойми, или не пустой))
вот именно! и твоя работа — чтобы юзер не страдал
GP
несложно опираться на статус