А мне ещё никто не смог показать как решать конфликты слияния через консоль за адекватное время. Когда над одним проектом работает более 2 человек нужен обзор дерева, который в любом gui выглядит лучше чем в консоли. При разборе ошибок и поиске виноватого быстрее в гуй, чем лупиться в двухцветную консоль после blame. Вся эта быстрота хороша для повседневных мелких операций.
Злоумышленник всегда может модифицировать код на фронте. И проверки флагов на бэкеде тут не помогут) С той же лёгкостью подменяется ответ... Это мнимая безопасность и, честно, непонятно, что вы этого не понимаете. Если у вас логика приложения целиком завязана на фронт и это ещё по безопасности бьёт, то у вашего приложения большие проблемы. Максимум что долго быть при несанкционированном доступе к флагам(а это не вот прям что-то супер важное) это переключение логики работы фронта. Если бэк не готов, то получаете ошибку на фронте. Ну включил для себя мамкин хакер новую кнопку, а она не работает - увы...
О каких высоконагруженных системах вы говорите? О реалтайм доступе к флагам каждые 5мс при работе? Флаги, они же часть конфигурации приложения, применяются при старте и до следующего перезапуска. Всё...
Но сколько же воды. Можно же это как-то проще донести! Плюсы и минусы без раздувания текста "белым шумом" Сами на проекте используем флаги и это очень удобно с точки зрения модульной разработки. Подход к работе с флагами должен быть регламентирован на уровне процесса разработки. Проверять фф на бекэнде полный бред. Фронт может и, обычно, разрабатывается быстрее бекэнда - сделал задачу закрыл флагом, перешёл к следующей. Очистка кодовой базы от выпущенных флагов должна быть организована на постоянной основе после каждого релиза.
Ну да и все эти пляски с бубнами только из-за того, что компонент Card криво написан. Все что необходимо это в калбеке onClick вернуть сущность card, ну или id. И все! Проблема решена! Не надо колхозить велосипеды. Всегда смотрите на свою архитектуру. Если вы начинаете что-то городить, это явный признак остановится и пересмотреть текущую реализацию компонентов
Да нет никакого смысла писать в резюме фразы "увеличил X на Y', "снизил X на Y" Во-первых это нельзя проверить, во-вторых нет методик, по которым это производилось. В целом выглядит как фантик. 90% резюме на рынке оверскильные. Это я говорю не как HR, а как человек, который проводит ТИ. Пишут всё подряд, даже если это был однократный опыт в школе. Задаешь вопрос по конкретике и поплыли.
Легко. За 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% от общего числа
А мне ещё никто не смог показать как решать конфликты слияния через консоль за адекватное время. Когда над одним проектом работает более 2 человек нужен обзор дерева, который в любом gui выглядит лучше чем в консоли. При разборе ошибок и поиске виноватого быстрее в гуй, чем лупиться в двухцветную консоль после blame. Вся эта быстрота хороша для повседневных мелких операций.
Злоумышленник всегда может модифицировать код на фронте. И проверки флагов на бэкеде тут не помогут) С той же лёгкостью подменяется ответ... Это мнимая безопасность и, честно, непонятно, что вы этого не понимаете. Если у вас логика приложения целиком завязана на фронт и это ещё по безопасности бьёт, то у вашего приложения большие проблемы. Максимум что долго быть при несанкционированном доступе к флагам(а это не вот прям что-то супер важное) это переключение логики работы фронта. Если бэк не готов, то получаете ошибку на фронте. Ну включил для себя мамкин хакер новую кнопку, а она не работает - увы...
О каких высоконагруженных системах вы говорите? О реалтайм доступе к флагам каждые 5мс при работе? Флаги, они же часть конфигурации приложения, применяются при старте и до следующего перезапуска. Всё...
Но сколько же воды. Можно же это как-то проще донести! Плюсы и минусы без раздувания текста "белым шумом" Сами на проекте используем флаги и это очень удобно с точки зрения модульной разработки. Подход к работе с флагами должен быть регламентирован на уровне процесса разработки. Проверять фф на бекэнде полный бред. Фронт может и, обычно, разрабатывается быстрее бекэнда - сделал задачу закрыл флагом, перешёл к следующей. Очистка кодовой базы от выпущенных флагов должна быть организована на постоянной основе после каждого релиза.
А что по вашему делает сейчас делает TS ?
Ну да и все эти пляски с бубнами только из-за того, что компонент Card криво написан. Все что необходимо это в калбеке onClick вернуть сущность card, ну или id. И все! Проблема решена! Не надо колхозить велосипеды. Всегда смотрите на свою архитектуру. Если вы начинаете что-то городить, это явный признак остановится и пересмотреть текущую реализацию компонентов
Да нет никакого смысла писать в резюме фразы "увеличил X на Y', "снизил X на Y" Во-первых это нельзя проверить, во-вторых нет методик, по которым это производилось. В целом выглядит как фантик. 90% резюме на рынке оверскильные. Это я говорю не как HR, а как человек, который проводит ТИ. Пишут всё подряд, даже если это был однократный опыт в школе. Задаешь вопрос по конкретике и поплыли.
Легко. За 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% от общего числа