Вот ничего подобного. Если компонент определен через стрелку на верхнем уровне, то нормально будет отображаться. Проблема будет при возврате из ХОФ, но для этого литер есть, который ругается
Вот как раз на этих языках он реализован нормально, а в JS/TS это огрызок. Да ещё и неявное создание другого объекта под капотом. Значение enum будет являться строгим строковым литералом, а значит ни одно сравнение с переменным вида string работать не будут - потребуется явное приведение в месте использования.
Очень много споров всегда идёт, что же все-таки использовать if или switch. Мы у себя на проекте приняли правило, что если требуется логика выбора по одному значению, то это switch. If используем только для логических выражений и вычислений
Статья - кликбейт. В первую очередь лодаш хейтят потому что неправильно делают импорты функций. И вместо 1кб заезжает в бандл вся библиотека из-за банального import _ from lodash. Во-вторых, перечисленные функции ну не самые интересные, по сравнению с set, pickBy, omitBy и merge. Там ещё много есть интересных функций. Да, многие уже устарели, но часть остаётся востребованной и никто не мешает сделать import omit from 'lodash/omit'...
К сожалению, у нас в стране очень узкий коридор для специалистов на плюсах. Геймдева нет, разработку бека на них тоже почти никто не делает, без qt нормального интерфейса не запилить, остальные фреймворки боль. Остаётся красноглазить на библиотеках и низкоуровневых решениях. Из-за этого перешёл на другие языки - боли меньше, вакансий больше. Из плюсов, простите за каламбур, потом любая типизация и дженерики как семечки
Ну прекратите уже говорит что есть очередь макрозадач. Это всего лишь название, а фактически это не очередь, а набор задач(set) Из статьи в статью копируют, а потом все удивляются, что новички не знают как на самом деле работает event loop. Вот что написано в спецификации "Task queues are sets, not queues, because the event loop processing model grabs the first runnable task from the chosen queue, instead of dequeuing the first task." https://html.spec.whatwg.org/multipage/webappapis.html#definitions-3
А мне ещё никто не смог показать как решать конфликты слияния через консоль за адекватное время. Когда над одним проектом работает более 2 человек нужен обзор дерева, который в любом gui выглядит лучше чем в консоли. При разборе ошибок и поиске виноватого быстрее в гуй, чем лупиться в двухцветную консоль после blame. Вся эта быстрота хороша для повседневных мелких операций.
Злоумышленник всегда может модифицировать код на фронте. И проверки флагов на бэкеде тут не помогут) С той же лёгкостью подменяется ответ... Это мнимая безопасность и, честно, непонятно, что вы этого не понимаете. Если у вас логика приложения целиком завязана на фронт и это ещё по безопасности бьёт, то у вашего приложения большие проблемы. Максимум что долго быть при несанкционированном доступе к флагам(а это не вот прям что-то супер важное) это переключение логики работы фронта. Если бэк не готов, то получаете ошибку на фронте. Ну включил для себя мамкин хакер новую кнопку, а она не работает - увы...
О каких высоконагруженных системах вы говорите? О реалтайм доступе к флагам каждые 5мс при работе? Флаги, они же часть конфигурации приложения, применяются при старте и до следующего перезапуска. Всё...
Но сколько же воды. Можно же это как-то проще донести! Плюсы и минусы без раздувания текста "белым шумом" Сами на проекте используем флаги и это очень удобно с точки зрения модульной разработки. Подход к работе с флагами должен быть регламентирован на уровне процесса разработки. Проверять фф на бекэнде полный бред. Фронт может и, обычно, разрабатывается быстрее бекэнда - сделал задачу закрыл флагом, перешёл к следующей. Очистка кодовой базы от выпущенных флагов должна быть организована на постоянной основе после каждого релиза.
Ну да и все эти пляски с бубнами только из-за того, что компонент Card криво написан. Все что необходимо это в калбеке onClick вернуть сущность card, ну или id. И все! Проблема решена! Не надо колхозить велосипеды. Всегда смотрите на свою архитектуру. Если вы начинаете что-то городить, это явный признак остановится и пересмотреть текущую реализацию компонентов
Да нет никакого смысла писать в резюме фразы "увеличил X на Y', "снизил X на Y" Во-первых это нельзя проверить, во-вторых нет методик, по которым это производилось. В целом выглядит как фантик. 90% резюме на рынке оверскильные. Это я говорю не как HR, а как человек, который проводит ТИ. Пишут всё подряд, даже если это был однократный опыт в школе. Задаешь вопрос по конкретике и поплыли.
Легко. За 30 минут могу по профилю составить примерный уровень. Томным он конечно не будет, но общая картина будет ясна. Я провел более 150 ТИ и у меня уже есть наработанные задачки, одна из которых это кусок кода по которому нужно провести ревью. Он достаточно простой, но в нём скрыто 10 недостатков, хотя с первого взгляда выглядит все ок. И вот тут сразу видно как человек размышляет, знает ли он определенные тонкости. Джуны, как правило, находят до 3-4 ) Мидлы до 6-7 И самое важное в этот момент я вижу как человек размышляет. Соответственно, все что сейчас делает, он понесет в твой проект точно также, , with no exceptions)
Это называется по-другому - я что-то накодил такое, что нормально нельзя покрыть юнит-тестами, но переделывать не буду, т.к. тесты отстой, а я гений!
Бегите из такой разработки. Это хаос и отсутствие системного подхода.
Вот ничего подобного. Если компонент определен через стрелку на верхнем уровне, то нормально будет отображаться. Проблема будет при возврате из ХОФ, но для этого литер есть, который ругается
Вот как раз на этих языках он реализован нормально, а в JS/TS это огрызок. Да ещё и неявное создание другого объекта под капотом. Значение enum будет являться строгим строковым литералом, а значит ни одно сравнение с переменным вида string работать не будут - потребуется явное приведение в месте использования.
Очень много споров всегда идёт, что же все-таки использовать if или switch. Мы у себя на проекте приняли правило, что если требуется логика выбора по одному значению, то это switch. If используем только для логических выражений и вычислений
Ничего интересного. Перед однокурсниками выпендриваться)
Статья - кликбейт. В первую очередь лодаш хейтят потому что неправильно делают импорты функций. И вместо 1кб заезжает в бандл вся библиотека из-за банального import _ from lodash. Во-вторых, перечисленные функции ну не самые интересные, по сравнению с set, pickBy, omitBy и merge. Там ещё много есть интересных функций. Да, многие уже устарели, но часть остаётся востребованной и никто не мешает сделать import omit from 'lodash/omit'...
Для этого есть sentry. Позиция автора статьи понятна, но выглядит как велосипед
Эмм.. а preserve log и unhandled exception breakpoints уже отменили ?
К сожалению, у нас в стране очень узкий коридор для специалистов на плюсах. Геймдева нет, разработку бека на них тоже почти никто не делает, без qt нормального интерфейса не запилить, остальные фреймворки боль. Остаётся красноглазить на библиотеках и низкоуровневых решениях. Из-за этого перешёл на другие языки - боли меньше, вакансий больше. Из плюсов, простите за каламбур, потом любая типизация и дженерики как семечки
От python и аннотации типов до TS и JS один шаг )
Ух, советы 30-летней давности подъехали) Без негатива...
Ну прекратите уже говорит что есть очередь макрозадач. Это всего лишь название, а фактически это не очередь, а набор задач(set) Из статьи в статью копируют, а потом все удивляются, что новички не знают как на самом деле работает event loop. Вот что написано в спецификации "Task queues are sets, not queues, because the event loop processing model grabs the first runnable task from the chosen queue, instead of dequeuing the first task." https://html.spec.whatwg.org/multipage/webappapis.html#definitions-3
А мне ещё никто не смог показать как решать конфликты слияния через консоль за адекватное время. Когда над одним проектом работает более 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)