Ужас, чтобы понять как работает компонент, нужно в шесть хуков провалиться.
Jsx в хуке! Что?! Зачем? Почему? Кровь из глаз...
Хуки созданы для переиспользования логики между компонентами! Чтобы то что раньше лежало в нескрльких componentDidUpdate не копипастить из компонента в компонент. Где тут переиспользование хоть чего либо? Зачем вёрстка в хуке??? В реакте уже есть функции, которые возвращают вёрстку jsx - они называются компоненты!!
"Ключ объекта всегда является строкой" - а вот и нет. Опять новичков ереси учите.
Ключ в самом объекте это строка ИЛИ символ.
Также если попытаться записать/взять значение по числовому ключу, он будет приведён к строке.
Ну и данная статья вводит в заблуждение в третьей части, что массивы и объекты - это разные сущности. А это не так! В JS все массивы являются объектами, так же как и функции.
От а до я говорите? А новичок поймёт, что будет если попытаться из массива взять что-то по индексу, которого там нет? А если положить в несуществующий индекс?
Думаю нет. Пусть лучше новичок learnjavascript почитает, будет полезнее
Про switch не сказали про то как объединять обработчики case, а главное, про то что case не создают свой scope по умолчанию (переменные объявленные кнутри case, видны снаружи)
Нанимать в ядерные технологии, доверяя аишке - это надо быть мегамозгом конечно. Надеюсь ума хватит хотя бы код для реакторов из чата гпт не копипастить.
Это нормальный паттерн использования реакт, когда реф не используется для дом элемента (если у тебя в return компонента какому-то диву реф присваивается, этот код выполнится тупо позже чем любые синхронные действия с рефом до return и всё перетрёт)
В useEventCallback дичь какая-то, зачем там layouteffect? Если хочешь юзколбек которому не нужен массив зависимостей и ссылка всегда стабильная, можно через рефы сделать
Это почему же? Тебе же не дают тестовое сделать, потратив n часов своего времени на код, который неизвестно посмотрят вообще или нет. На лайвкодинге дают задачи, которые можно решить за 5-10 мин в плане сложности - и смотрят даже не на ответ, а на ход рассуждений. Это может не нравиться если ты например не умеешь думать...
Киньте в меня тапок, если я не прав, но нафига делать электрический контакт струн с темброблоком? Чтобы играть как волк из ну погоди, втыкая гитару в розетку?
То есть чтобы проапдейтить какой-то сильно вложенный плейсхолдер, ты ререндеришь всё приложение, а потом пытаешься пофиксить посадку перформанса мемоизацией логики в компонентах которые посередине вложены?
Вот после таких решений и рождаются анекдоты про программистов и их костыли.
Никто не говорит "функции обратного вызова" - все говорят "колбэк".
Также написана ересь про ненужные создания функций при ререндерах. Юзколбэк нужен чтобы передавать стабильную ссылку на функцию - всё. Но на каждый ререндер вы всё равно создаёте и прокидываете в него новую функцию. Оптимизация будет только если есть дочерние компоненты, обёрнутые memo
Ужас, чтобы понять как работает компонент, нужно в шесть хуков провалиться.
Jsx в хуке! Что?! Зачем? Почему? Кровь из глаз...
Хуки созданы для переиспользования логики между компонентами! Чтобы то что раньше лежало в нескрльких componentDidUpdate не копипастить из компонента в компонент. Где тут переиспользование хоть чего либо? Зачем вёрстка в хуке??? В реакте уже есть функции, которые возвращают вёрстку jsx - они называются компоненты!!
"Ключ объекта всегда является строкой" - а вот и нет. Опять новичков ереси учите.
Ключ в самом объекте это строка ИЛИ символ.
Также если попытаться записать/взять значение по числовому ключу, он будет приведён к строке.
Ну и данная статья вводит в заблуждение в третьей части, что массивы и объекты - это разные сущности. А это не так! В JS все массивы являются объектами, так же как и функции.
От а до я говорите? А новичок поймёт, что будет если попытаться из массива взять что-то по индексу, которого там нет? А если положить в несуществующий индекс?
Думаю нет. Пусть лучше новичок learnjavascript почитает, будет полезнее
Я так понял в примере использования хука намеренно options не прокидываются, потому что иначе компонент в бесконечный цикл обновлений уходит?
Про switch не сказали про то как объединять обработчики case, а главное, про то что case не создают свой scope по умолчанию (переменные объявленные кнутри case, видны снаружи)
Такие вредные советы ещё и от имени компании писать не стыдно? Пример с хуком приведёт к бесконечному циклу перерендеров компонента.
А ещё в блоке 3 "нужно сериализовать данные" пункты по два раза повторяются.
Формулировка задачи (особенно картинки) выглядит, как будто её можно решить через css без обсерверов, просто надо базово знать гриды
Начал читать, увидел форвардреф, закрыл...
Нанимать в ядерные технологии, доверяя аишке - это надо быть мегамозгом конечно. Надеюсь ума хватит хотя бы код для реакторов из чата гпт не копипастить.
Статья интересная, но клиентский и серверный код свален в кучу
В целом довольно слабо, уровень джуна. Претиер/линтер хотя бы для статьи можно было настроить, чтобы например = не стояло вплотную к переменной.
Но вишенка на торте конечно var и классовые реакт компоненты в 2025 году
Это нормальный паттерн использования реакт, когда реф не используется для дом элемента (если у тебя в return компонента какому-то диву реф присваивается, этот код выполнится тупо позже чем любые синхронные действия с рефом до return и всё перетрёт)
В useEventCallback дичь какая-то, зачем там layouteffect? Если хочешь юзколбек которому не нужен массив зависимостей и ссылка всегда стабильная, можно через рефы сделать
Это почему же? Тебе же не дают тестовое сделать, потратив n часов своего времени на код, который неизвестно посмотрят вообще или нет. На лайвкодинге дают задачи, которые можно решить за 5-10 мин в плане сложности - и смотрят даже не на ответ, а на ход рассуждений. Это может не нравиться если ты например не умеешь думать...
Так про любую задачу можно ответить: гуглим пакет, в котором есть данная функция и устанавливаем его.
Киньте в меня тапок, если я не прав, но нафига делать электрический контакт струн с темброблоком? Чтобы играть как волк из ну погоди, втыкая гитару в розетку?
Щас бы на варах и jQuery писать в 2025
То есть чтобы проапдейтить какой-то сильно вложенный плейсхолдер, ты ререндеришь всё приложение, а потом пытаешься пофиксить посадку перформанса мемоизацией логики в компонентах которые посередине вложены?
Вот после таких решений и рождаются анекдоты про программистов и их костыли.
Реакт 19 уже официально вышел без всяких канареек
Никто не говорит "функции обратного вызова" - все говорят "колбэк".
Также написана ересь про ненужные создания функций при ререндерах. Юзколбэк нужен чтобы передавать стабильную ссылку на функцию - всё. Но на каждый ререндер вы всё равно создаёте и прокидываете в него новую функцию. Оптимизация будет только если есть дочерние компоненты, обёрнутые memo