Легко. За 30 минут могу по профилю составить примерный уровень. Томным он конечно не будет, но общая картина будет ясна. Я провел более 150 ТИ и у меня уже есть наработанные задачки, одна из которых это кусок кода по которому нужно провести ревью. Он достаточно простой, но в нём скрыто 10 недостатков, хотя с первого взгляда выглядит все ок. И вот тут сразу видно как человек размышляет, знает ли он определенные тонкости. Джуны, как правило, находят до 3-4 ) Мидлы до 6-7 И самое важное в этот момент я вижу как человек размышляет. Соответственно, все что сейчас делает, он понесет в твой проект точно также, , with no exceptions)
Нет, не должны. Это порочная практика, раздуваемая в сообществе. Вместо стандартного подхода к обработке ошибок приходится делать несколько кругов ада обработки. И самое интересное, что ценности у такого решения 0. Что мешает в той же 400 вернуть дополнительный код. 400 это как раз код ошибки про ту самую бизнес логику. И далее, для чего все это? Дать пользователю какой-то внятный ответ? Зачем? Чтобы что? Чтобы он, получив сообщение, пошел в службу поддержки? Для этого нет необходимости ок200 использовать. Второй момент - возврат внутренних кодов ошибок по бизнес логике это частичное раскрытие внутренней реализации, что не очень хорошо. Есть куча сервисов, тот же sentry например, которые помогут вам на проде собрать ошибки. Не пишите костыли.
Если useDerivedState нужен для первоначального состояния, то может использовать нормальные инструменты форм? Например Final Form, потому как в вашем примере работа идёт именно с полями ввода данных
И в итоге получаем компонент-мультитул. Тут и загрузка данных, и обработка ошибок, мапинг входных данных, формирование представления. Это подойдёт разве что для пет проекта, а в контексте статьи для проверки на джуна. Поменяйте роут с данными и придется 80% компонента переписать заново. Про тестирование я уже молчу
Простите, но запрос данных в эффекте это моветон. Если нужна загрузка данных, то ее надо оформлять хуком и делать функциональную композицию на уровне "умного" компонента(контроллера)
По теории вероятности, если миллиону обезьян дать пишущую машинку, то рано или поздно они напишут "Войну и Мир". Развитие интернета доказало, что это не так. Не мое) Смотреть в консоль и запомнить как работает таймаут и действительно понять как это работает - разные вещи. Есть же куча нюансов - обработка ошибки, возврат значений по цепочке, finally и т.д.
С промисами не надо играться. Самое первое что надо сделать - это прочитать и понять документацию. И только потом начинать что-то делать. Тут простым тыканием setTimeout не обойтись.
Руки рубит за такое. Периодически встречаю такие подходы и удивляюсь! Возвращать ОК200 с кодом ошибки зачем? Чтобы что? Есть определенный стандарт ошибок, которые закрывают 99.9% случаев. В результате вместо нормальной обработки ошибок ты пишешь двойной парсер с лапшой
О-хо-хо. А вам в панамку не напихали ещё за описание работы хука? При использовании реакт всегда! создаёт новый экземпляр функции и либо отбрасывает его, если зависимости не поменялись, либо возвращает старую ссылку на функцию. "On the following renders, React will compare the dependencies with the dependencies you passed during the previous render. If none of the dependencies have changed (compared with Object.is), useCallback will return the same function as before. Otherwise, useCallback will return the function you passed on this render"
Судя по тексту вы решаете проблему некачественных моков не путем их правильного и корректного описания, а путем создания дополнительной сущности в виде Fake Database. При этом уж там-то вы не можете ошибиться, правда? Из проблем, которые я тут вижу - это появляется связанность приложения с дополнительной сущностью. Невозможно разрабатывать приложения через подход API First. Как уже правильно было отмечено, моки позволяют моделировать различные ситуации, сложно воспроизводимые в реальности. Появляется дополнительная точка обслуживания/отказа. Я как фронт-разработчик могу, но не обязан разбираться в тонкостях работы с конкретной бд, ее таблицами и запросами. Опять же - наполненность данными. Фейковые данные составляют те же люди, но тут они уже не ошибаются? Ваше утверждение очень спорное. По своему примеру скажу, что у нас на 2 проектах порядка 1500 юнит тестов написанных на моках. Изредка их приходится обслуживать, зачастую это коррекция архитектуры, но это не более 1% от общего числа
Соглашусь со спеллчекером. Остальное, как и говорил - мусор. Для чего нужны "выразительные" комментарии? Все Todo будут автоматически собраны при генерации документации + настройте сонар, так он ещё и code smelt покажет. Что за инфантильность я, честно, не понимаю) Отступы в студии прекрасно видно в виде вертикальных серых линеек и без дополнительных плагинов.
BetterComments в помойку, для этого есть JSDoc, который заодно приучает писать документацию. Code Spell Checker туда же, ставим ESLint и настраиваем любые правила. К тому-же, VSCode можно настроить так, чтобы ошибки устранялись автоматически при сохранении с помощью этого линтера. Соответственно, rainbow тоже не нужен - настраиваем правило литера для отступов - студия сама подсветит и предложить вариант замены
Легко. За 30 минут могу по профилю составить примерный уровень. Томным он конечно не будет, но общая картина будет ясна. Я провел более 150 ТИ и у меня уже есть наработанные задачки, одна из которых это кусок кода по которому нужно провести ревью. Он достаточно простой, но в нём скрыто 10 недостатков, хотя с первого взгляда выглядит все ок. И вот тут сразу видно как человек размышляет, знает ли он определенные тонкости. Джуны, как правило, находят до 3-4 ) Мидлы до 6-7 И самое важное в этот момент я вижу как человек размышляет. Соответственно, все что сейчас делает, он понесет в твой проект точно также, , with no exceptions)
Нет, не должны. Это порочная практика, раздуваемая в сообществе. Вместо стандартного подхода к обработке ошибок приходится делать несколько кругов ада обработки. И самое интересное, что ценности у такого решения 0. Что мешает в той же 400 вернуть дополнительный код. 400 это как раз код ошибки про ту самую бизнес логику. И далее, для чего все это? Дать пользователю какой-то внятный ответ? Зачем? Чтобы что? Чтобы он, получив сообщение, пошел в службу поддержки? Для этого нет необходимости ок200 использовать. Второй момент - возврат внутренних кодов ошибок по бизнес логике это частичное раскрытие внутренней реализации, что не очень хорошо. Есть куча сервисов, тот же sentry например, которые помогут вам на проде собрать ошибки. Не пишите костыли.
Если useDerivedState нужен для первоначального состояния, то может использовать нормальные инструменты форм? Например Final Form, потому как в вашем примере работа идёт именно с полями ввода данных
И в итоге получаем компонент-мультитул. Тут и загрузка данных, и обработка ошибок, мапинг входных данных, формирование представления. Это подойдёт разве что для пет проекта, а в контексте статьи для проверки на джуна. Поменяйте роут с данными и придется 80% компонента переписать заново. Про тестирование я уже молчу
Простите, но запрос данных в эффекте это моветон. Если нужна загрузка данных, то ее надо оформлять хуком и делать функциональную композицию на уровне "умного" компонента(контроллера)
Чем husky и stylint обидели, что их не включили?
Ну это же два принципиально разных метода! all используется для случая "все или ничего" allSettled для случая "дай хоть что-то"
По теории вероятности, если миллиону обезьян дать пишущую машинку, то рано или поздно они напишут "Войну и Мир". Развитие интернета доказало, что это не так. Не мое) Смотреть в консоль и запомнить как работает таймаут и действительно понять как это работает - разные вещи. Есть же куча нюансов - обработка ошибки, возврат значений по цепочке, finally и т.д.
С промисами не надо играться. Самое первое что надо сделать - это прочитать и понять документацию. И только потом начинать что-то делать. Тут простым тыканием setTimeout не обойтись.
Руки рубит за такое. Периодически встречаю такие подходы и удивляюсь! Возвращать ОК200 с кодом ошибки зачем? Чтобы что? Есть определенный стандарт ошибок, которые закрывают 99.9% случаев. В результате вместо нормальной обработки ошибок ты пишешь двойной парсер с лапшой
О-хо-хо. А вам в панамку не напихали ещё за описание работы хука? При использовании реакт всегда! создаёт новый экземпляр функции и либо отбрасывает его, если зависимости не поменялись, либо возвращает старую ссылку на функцию.
"On the following renders, React will compare the dependencies with the dependencies you passed during the previous render. If none of the dependencies have changed (compared with Object.is), useCallback will return the same function as before. Otherwise, useCallback will return the function you passed on this render"
Чем вам шаблоны не угодили? ) И какие новые проблемы они создают?
И если данные одной строки поменялись в БД, то начинай сначала. Выборка с фильтрами из БД будет быстрее, чем та же самая фильтрация на фронте.
Судя по тексту вы решаете проблему некачественных моков не путем их правильного и корректного описания, а путем создания дополнительной сущности в виде Fake Database. При этом уж там-то вы не можете ошибиться, правда? Из проблем, которые я тут вижу - это появляется связанность приложения с дополнительной сущностью. Невозможно разрабатывать приложения через подход API First. Как уже правильно было отмечено, моки позволяют моделировать различные ситуации, сложно воспроизводимые в реальности. Появляется дополнительная точка обслуживания/отказа. Я как фронт-разработчик могу, но не обязан разбираться в тонкостях работы с конкретной бд, ее таблицами и запросами. Опять же - наполненность данными. Фейковые данные составляют те же люди, но тут они уже не ошибаются? Ваше утверждение очень спорное. По своему примеру скажу, что у нас на 2 проектах порядка 1500 юнит тестов написанных на моках. Изредка их приходится обслуживать, зачастую это коррекция архитектуры, но это не более 1% от общего числа
А в чем проблема? Сейчас все фреймворки умеют в TS. Другое дело, что его не хотят молодые. Это же так сложно!)
И причем здесь TypeScript? Кликбейт одним словом...
После "мАзолить" и "кАпнуть" перестал читать. ТС, без негатива, но к читателям надо с б'ольшим уважением подходить
Соглашусь со спеллчекером. Остальное, как и говорил - мусор. Для чего нужны "выразительные" комментарии? Все Todo будут автоматически собраны при генерации документации + настройте сонар, так он ещё и code smelt покажет. Что за инфантильность я, честно, не понимаю) Отступы в студии прекрасно видно в виде вертикальных серых линеек и без дополнительных плагинов.
BetterComments в помойку, для этого есть JSDoc, который заодно приучает писать документацию. Code Spell Checker туда же, ставим ESLint и настраиваем любые правила. К тому-же, VSCode можно настроить так, чтобы ошибки устранялись автоматически при сохранении с помощью этого линтера. Соответственно, rainbow тоже не нужен - настраиваем правило литера для отступов - студия сама подсветит и предложить вариант замены
Дядь, не душни ;)