Комментарии 25
Если я правильно понял, то текст ошибки приходит с сервера. Я вообще не React-разработчик, но почему так нельзя? Многие backend-фреймворки умеют валидировать данные и выводить текст ошибок. Какой смысл его (текст ошибки) переопределять на фронтенде?
Имхо, вся обязанность бэкенда — это отдать код ошибки и все полезные с ней данные, а как отобразить ее пользователю и на каком языке — это уже ответственность клиентской части.
Как вам такой дизайн. Бэкэнд выдает ошибку, а фронт обращается к бэку еще раз с ошибкой и нужным языком, чтобы получить текст ошибки?
А плодить кучу запросов, мне кажется совсем не верным решением.
Или что-то свое кастомное? Не приведет ли кастомное к ошибкам. Например сервер возвращает строку «wrong_email_or_password», а на клиенте при проверке на равенство я потерял букву.
Кастомные. Тут можно использовать строковые константы. Если бэкенд на ноде, то можно использовать общий код, иначе держать константы в синхронизированном виде для обоих частей.
Скажу только об "общем" списке ошибок.
Не поймите неправильно, но на мой взгляд, практически каждая из ошибок — ошибка невнимательности или лени. И я более, чем убежден, что часть вины в задании(двух), полностью описанном текстом(ни макетов, ни примера) и структурированом таким образом, что респонднту определенно придется бегать по всему тексту глазами. Некоторых моментов (например последний пункт), я вовсе не нашел бегло разглядывая задание.
И хотя ошибки невнимательности определенно важны при собеседовании, они не несут никакой реальной информации, помимо того, что респондент не готов тратить время, требуемое для выполнения этого задания(двух).
P.S. Надеюсь не обидетесь, в прошлом ваши статьи не читал, поэтому попросил бы разъяснить значение термина "junior-react" из заголовка.
Про детали и лень — хороший пример. Если делаешь — делай хорошо. Фронтенд, это не только про «вау как здорово и классно, и платят много», это так же про не любимые «доработки/допиливания» мелких деталей, особенно возня с формами и ошибками как раз. Мы на видео этого коснулись. На трансляции некоторые ребята ответили — да, было лень. С ленью надо работать. Заодно они увидели реальные примеры того, что им могут отправить на доработку после code-review. Поэтому, я считаю, что это «несет реальную информацию».
p.s. хабр взрастил какой-то пласт обидчивых авторов и комментаторов?) Конструктивная критика всегда хорошо, никаких обид. Для меня junior react — начинающий разработчик (фронтендер), который пишет на стэке react. Это отчасти и начинающий javascript разработчик, или не начинающий js разрабочтик, но начинающий в react, или наоборот ничего не знающий в javascript, но так же тот, кто начал свой путь с react.
p.s. надо подумать, как можно сделать анонс и не разгневать публику. Аккаунт с карточкой подписи, в которой можно указать vk/telegram и тд на 3 месяца стоит дорого (14 тысяч), и тоже не особо позволяет постить ссылки в самой статье, а корпоративный аккаунт стоит и того дороже (было 70).
Иконка Web выносится вперед в компоненте (а лучше бы в редьюсере, или экшене);
А если будет два компонента, в одном из которых нужно иконку отрисовать первой, а в другом — последней?
1) диспатчнуть два экшена (например, SET_ICONS_FOR_COMP_A и SET_ICONS_FOR_COMP_B)
2) делать это в компоненте
В зависимости от частоты перерисовок компонента и каких-то еще условиий задачи, можно выбрать то, что больше подойдет. Мне пока импонирует вариант 1.
Так или иначе, в задаче хотелось показать, что если вам с бэкэнда пришли не угодные данные, то на мой взгляд, лучше их «перевернуть» в редьюсере.
1) диспатчнуть два экшена (например, SET_ICONS_FOR_COMP_A и SET_ICONS_FOR_COMP_B)
Тогда либо вы храните одну копию данных и последовательное выполнение второго экшена "сломает" данные предыдущего (что ломает логику приложения, если оба компонента находятся на странице одновременно либо отображаются друг за другом без перезагрузки данных), либо вы храните две копии и это нарушает SSOT.
Так или иначе, в задаче хотелось показать, что если вам с бэкэнда пришли не угодные данные, то на мой взгляд, лучше их «перевернуть» в редьюсере.
Все зависит от того, что считать "неугодными".
Система стор-экшоны-редьюсер — это m из mvc, модель ничего не должна знать о свойствах вида (о том, что вашему виду нужно вывести какой-это элемент первым). Это целиком и полностью ответственность вида, то есть компонента. В модели данные могут вообще находиться в сильно другой форме, чем потом выводится пользователю.
Если же есть какие-то ограничения на данные, которые следуют непосредственно из предметной области — тогда да, следует провести преобразование в редьюсере/экшоне.
Отсутствуют или недостаточно подробно описаны Prop Types.
Я всегда считал, что PropTypes — это фишка только для development-версии. Когда это ещё было встроенным функционалом React.js, это игнорировалось в продакшене, потому что даёт снижение производительности приложения, (Насколько я понимаю, отдельный пакет prop-types, который появился после версии 15.5, тоже работает только в режиме development.)
По сути, PropTypes отрабатывает только в режиме разработки. Это значит, что если в продакшене для какого-то свойства был передан неподходящий параметр, продакшн от этого не будет защищён, потому что вся ответственность за типы была передана в PropTypes, который в продакшене игнорируется. Когда навязывается использование PropTypes, у разработчиков складывается ложное впечатление, что они предусмотрели больше, чем это есть на самом деле, что ведёт к снижению качества продукта.
По сути, нет смысла тратить время на PropTypes. Лучше его потратить на то, чтобы компонент самостоятельно мог выдавать ошибки или мог принудительно генерировать дефолтные значения для props, если ничего не было передано (или конвертировать входные значения в подходщий формат, если они имеют неправильный). Чтобы PropTypes мог это делать, нужно либо использовать в продакшене development-версию React, либо модифицировать его, чтобы PropTypes мог работать в продакшене.
Основная моя критика в этом:
- В режиме production PropTypes не защищает от неправильных входных данных;
- В режиме production PropTypes нарушает ещё один ваш критерий оценки: «Не удален „старый код“, то есть такой код, который нигде не используется»
PropTypes — это некий конспект того, что должно приходить в компонент и в каком виде. В процессе разработки и поддержки — это очень удобно. Конечно, игнорирование предупреждений или внезапное изменение чего-то от бэкэнда, приведет к проблемам в production версии.
чтобы компонент самостоятельно мог выдавать ошибки или мог принудительно генерировать дефолтные значения для props, если ничего не было передано (или конвертировать входные значения в подходщий формат, если они имеют неправильный)
Здесь +1, но не согласен, что делать это «лучше, вместо описывания PT».
p.s. вместе с flow, propTypes становятся еще более удобными в режиме разработки и поддержки.
p.s. вместе с flow, propTypes становятся еще более удобными в режиме разработки и поддержки.
В режиме поддержки PropTypes не становятся более удобными, потому что поддержка обычно осуществляется для пользователей, а пользователи — это те, кто использует production-версию, и в режиме поддержки приходится обычно работать с кодом и логами оттуда, где PropTypes не работают.
Лучше его потратить на то, чтобы компонент самостоятельно мог выдавать ошибки или мог принудительно генерировать дефолтные значения для props, если ничего не было передано
Дык это будет не бесплатно. Любой runtime-код это runtime-код. Вне зависимости от того, библиотечный он или нет. Проверок PropTypes нет в prod-коде именно из-за этого. Также как и никто не прогоняет тесты на машинах клиентов, их прогоняют на build-серверах, на локальных машинах разработчиков. DEV-инструменты это DEV-инструменты. Также как и eslint…
В общем ваша критика непонятна. PropTypes очень сильно выручают в случае, если вы не используете flow или TypeScript. А вот насколько они нужны, если всё таки статическая типизация используется я судить не берусь.
так что данная статья больше подходит для самих джунов и тех, кто их будет нанимать. Для мидла и выше подобное уже не котируется, сказывается опыт в проектах и способы решения проблем.
Code-review тестового задания junior react разработчиков