Что-то я не понимаю, зачем какие-то чейны, если задача из примера - типичный дебаунс. Создаём тайммаут, создаём функцию, которая отменяет таймаут - profit.
Правильнее считать не отработки юзеффекта, а вызов рендера компонента. В чём разница? Оно конечно будет хорошо работать когда рендеров относительно мало (меньше 60 в сек), а вот если в компонент может прилетать например новый проп раз 100500 в секунду (мы же ведь для дебага эту херню собрались использовать), то есть подозрение, что юзэффект может исполниться "когда-нибудь" и вовсе не отразит реальную нагрузку.
И это не сферический случай в вакууме, приходилось как-то дебажить, что юзэффект отрабатывал через минуту после того как "должен был"
Неплохо было бы, если бы "правильные" ответы на вопросы для джунов не содержали ошибок. Например про реакт фрагмент 2 формы записи на то и 2, что имеют различия (в сокращённой записи нельзя прописать key)
Прежде чем в меня кидаться докой из ui библиотеки, можно почитать доку родного html диалога и в чем там разница между модальным и немодальным диалогом, чтобы не мешать тёплое с мягким.
Ну а по поводу анимации - это не опять же не придирка. Одна из главных проблем модалок/попапов - когда их может быть не одна, нужно грамотно ждать пока закроется одно прежде чем открывать другое. Хранить состояние диалогового окна в ячейке стора, как это показано в примере статьи - тут много ума не надо, это может сделать любой за 5 минут
Всё начинает идти не так с описания шага 1. ModalNames у нас какого-то лешего с большой буквы, хотя это не тип, и даже не енум, и уж тем более не класс.
"Строгая типизация обеспечивает дополнительную уверенность и удобство" - нет, она не работает в рантайме. Тайпскрипт никак не запретит вызвать второе окно когда открыто первое.
Ключи в объекте, задаваемые через манипуляцию со строками, и функция capitalizeFirstLetter - это что вообще за нафиг??
По функционалу - конечно же эта приблуда не дружит с анимациями исчезновения, это можно заметить даже визуально когда пропадает попап с данными (остаются названия полей, а значений нет) и layout shift может быть гораздо больше если там картинка какая или большой текст. А если в одном попапе юзер нажмёт условное "да", а скажем средств не хватает и юзеру нужно показать ошибку? Где закрытие одного (ждем анимацию) и только потом открытие следующего?
И вишенка на торте - это ни разу не модалка а попап. А бизнесу может быть надо функционал именно модалки, что её не закроешь пока допустим юзер не тыкнет "да согласен".
Что-то я не понимаю, зачем какие-то чейны, если задача из примера - типичный дебаунс. Создаём тайммаут, создаём функцию, которая отменяет таймаут - profit.
Сразу после подзаголовка "Что нового в Next.js15?" пропал кусок текста.
Скачаются минифицированные скрипты, рассчитанные на бэк и юрлы сайта. Что ты будешь делать с этим всем?
Тротлинг через таймаут - сомнительно. Он не будет работать в тяжёлых задачах.
Про ивентлуп конечно ересь понаписали. Он есть в браузере, есть в ноде, но не в самом js.
Пример про лисков какая-то фигня, там нету никакого реакт компонента
Одно из самых бесячих Enter как "интер". Кроме как любовью к итальянской футбольной команде не знаю, как объяснить такое произношение.
Ты чё с ума сошёл, then - метод промисов и не надо никогда называть свою кастомную хрень как системную функцию!!
В десктопной версии конечно есть девтулзы из которых что угодно можно удалить уже 1000 лет как. Но анимация конечно мемная: "ты чиво наделал?"
То, что спрашивают на собесе у джунов и о чём явно написано в документации, стало открытием для автора статьи.
Колбэки, возвращаемые из хуков, должны иметь стабильную ссылку - а не как здесь
Правильнее считать не отработки юзеффекта, а вызов рендера компонента. В чём разница? Оно конечно будет хорошо работать когда рендеров относительно мало (меньше 60 в сек), а вот если в компонент может прилетать например новый проп раз 100500 в секунду (мы же ведь для дебага эту херню собрались использовать), то есть подозрение, что юзэффект может исполниться "когда-нибудь" и вовсе не отразит реальную нагрузку.
И это не сферический случай в вакууме, приходилось как-то дебажить, что юзэффект отрабатывал через минуту после того как "должен был"
Неплохо было бы, если бы "правильные" ответы на вопросы для джунов не содержали ошибок. Например про реакт фрагмент 2 формы записи на то и 2, что имеют различия (в сокращённой записи нельзя прописать key)
На дворе 2024 год, кто-то до сих пор использует var и пишет function ObjectCreator вместо class...
Прежде чем в меня кидаться докой из ui библиотеки, можно почитать доку родного html диалога и в чем там разница между модальным и немодальным диалогом, чтобы не мешать тёплое с мягким.
Ну а по поводу анимации - это не опять же не придирка. Одна из главных проблем модалок/попапов - когда их может быть не одна, нужно грамотно ждать пока закроется одно прежде чем открывать другое. Хранить состояние диалогового окна в ячейке стора, как это показано в примере статьи - тут много ума не надо, это может сделать любой за 5 минут
Это джун писал?
Всё начинает идти не так с описания шага 1. ModalNames у нас какого-то лешего с большой буквы, хотя это не тип, и даже не енум, и уж тем более не класс.
"Строгая типизация обеспечивает дополнительную уверенность и удобство" - нет, она не работает в рантайме. Тайпскрипт никак не запретит вызвать второе окно когда открыто первое.
Ключи в объекте, задаваемые через манипуляцию со строками, и функция capitalizeFirstLetter - это что вообще за нафиг??
По функционалу - конечно же эта приблуда не дружит с анимациями исчезновения, это можно заметить даже визуально когда пропадает попап с данными (остаются названия полей, а значений нет) и layout shift может быть гораздо больше если там картинка какая или большой текст. А если в одном попапе юзер нажмёт условное "да", а скажем средств не хватает и юзеру нужно показать ошибку? Где закрытие одного (ждем анимацию) и только потом открытие следующего?
И вишенка на торте - это ни разу не модалка а попап. А бизнесу может быть надо функционал именно модалки, что её не закроешь пока допустим юзер не тыкнет "да согласен".
Вообще если в какой-то библиотеке кривая типизация - правильнее будет исправить типы, чем расставлять игноры по коду
Я человек простой - вижу var в js коде, дальше не читаю...
А неужто редактор кода не подсвечивает ошибки в коде или это честно стыренная с буржуйских инетов статья?
Там где App, нет закрывающего тега.
А нет подождите там вообще подсветка синтаксиса путает контент с кусками кода судя по Available in и рандомно покрашенным html тегам.
А ещё тег стронг ляпают для стилизации(
Смысл статьи в чём?
"Обфусцируйте код чтобы его не прочитали, а вот ресурсы которые в 1 клик деобфусцируют ваш якобы защищенный код" ?
Котлин js - так и просится картинка со слонопингвином с ковчега. А главное непонятно зачем?