Как стать автором
Обновить

Комментарии 9

Среди альтернатив стоит указать веб-компоненты, которые уже являются стандартом и получают нативную поддержку в браузерах в этом году (пока требуется полифил). Этот подход делает React в качестве решения для декомпозиции интерфейса не самым оптимальным, а такая штука как Polymer — делает работу с компонентами весьма приятной (скоро выходит Polymer 2, в котором описание компонентов будет ближе к ванильному). Помимо этого, веб-компоненты позволяют произвольно совмещать обычную верстку и кастомные теги со сложной логикой внутри, а значит и использовать любые серверные шаблонизаторы (в отличие от того-же React).

Я бы еще добавил, что Vue позволяет писать свои .vue-компоненты в виде, очень близком к стандарту веб-компонентов (та же структура, слоты, эмуляция изолированных стилей). В будущем это позволит легко переключиться на нативную поддержку.

Вторая версия компонент — это да, сказка. Жду не дождусь когда она уже в обычном хроме будет по умолчанию доступна.

А чего ждать то? Google используют в продакшене. Когда совсем станет мейнстримом — лучше быть во всеоружии и уже сейчас как следует объездить эту лошадку, хотя-бы пока с помощью полифиллов. Я уже более года как перешел с Реакта на веб-компоненты, и не жалею ни капли. Это ведь не какой-то очередной "супер-пупер-фреймфорк тм", а стандарт.

Так то я уже пользую в одном своем проекте, причем вместе с tsx — очень удобно, шаблоны получается не нужны. Эдакий реакт на компонентах. Но нативно они только в канарейке работают, я об этом. Про полифилл в курсе.

Согласен. Мне лично в реакте не нравится сама абстракция — то, что реакт компонент — это не нативный кастомный элемент.
Ну а с полимером сложно работать ввиду никакой поддержки ES6, webpack — того стэка, к удобству которого привыкаешь очень быстро. Во второй версии вроде как это частично обещают исправить, ждем.
Если API разрабатываются отдельно, то ошибка обрабатывается по HTTP коду или кастомному строчному коду, это лучше делать сразу в методе сервиса который делает AJAX запрос.
Остальные ошибки чаще всего вообще никак не обрабатываются, предполагается что их быть не должно, а если все-таки случились, пользователь догадается перегрузить страницу."


Нет ли всё-таки другого варианта сообщить о «странном» ответе от сервера? Насколько я могу судить — это очень болезненная тема в разработке с ajax-запросами. Ведь ошибки бывают в бизнеслогике и её уже никак не свалить на код 500. В этом случае сервер будет пытаться честно предупредить клиента. Что же делать клиенту? Вдруг у него форма на 20-30 полей и перезагрузка страницы ооочень расстроит его. Простите, что несколько придираюсь и утрирую, но не может быть, чтобы не было решения?

Общепринятая практика при разработке API при ошибке вернуть подходящий ошибочный HTTP код (не 200) и какие-то данные об ошибке. На своих проектах я предпочитаю при любой ошибке возвращать стандартный ошибочный код 500 (Server Error) и передавать строковый код ошибки (например no_rights_to_edit), тогда на клиенте можно проверить код ошибки и в зависимости от него показывать нужное сообщение. Если при этом API используются только для одного клиента, то можно сразу с сервера передавать сообщение, которое можно показать на клиенте.


Ошибки AJAX запросов можно и нужно обрабатывать. Я имел в виду, что не обрабатываются другие ошибки, например обращение к underfined переменной или прочие непредвиденные ситуации.

undefined — это работа на клиенте, тут всё просто и по идее до клиента такие ошибки доходить не должны.

Просто если сосредоточиться на обработке ошибок ajax, то с сервера в ответ на ajax запрос может прийти ответ, к которому клиент совсем не будет готов и при этом это не будет ошибкой сервера! Ошибку может сгенерировать фильтр сервера, когда до вашего приложения дело ещё не дошло и формат ошибки тоже может быть неожиданным для клиента. Вот вы ожидаете text, а приходит xml или json, а может csv!? Но это тоже не гарантия, что сервер вернул вам что-то из разряда того, что вы ожидаете и что именно ваше приложение сформировало сообщение об ошибке.
За те года, что существует ajax я не видел универсального решения этой проблемы. Ведь проблема формулируется просто — надо как-то дать понять, что именно моя программа обработала запрос. Даже если вы возвращаете ошибку 500 это не гарантирует клиенту, что именно ваша серверная часть вернула эту ошибку. По сути 500 ошибку, которую сгенерировала ваша программа не отличить от такой же ошибки, сгенерированной самим сервером. Процентах в 90 случаев это может выручить, но никогда нельзя быть уверенным, что если в вашем проекте на тесте надежда что 90% уверенности работали в 100% случаев, то в продакшене не случиться, что эти 90% уверенности работают только в 50% случаев, а то и меньше.

Простите за занудство. Меня эта проблема бесит. :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории