Правильнее считать не отработки юзеффекта, а вызов рендера компонента. В чём разница? Оно конечно будет хорошо работать когда рендеров относительно мало (меньше 60 в сек), а вот если в компонент может прилетать например новый проп раз 100500 в секунду (мы же ведь для дебага эту херню собрались использовать), то есть подозрение, что юзэффект может исполниться "когда-нибудь" и вовсе не отразит реальную нагрузку.
И это не сферический случай в вакууме, приходилось как-то дебажить, что юзэффект отрабатывал через минуту после того как "должен был"
Неплохо было бы, если бы "правильные" ответы на вопросы для джунов не содержали ошибок. Например про реакт фрагмент 2 формы записи на то и 2, что имеют различия (в сокращённой записи нельзя прописать key)
Прежде чем в меня кидаться докой из ui библиотеки, можно почитать доку родного html диалога и в чем там разница между модальным и немодальным диалогом, чтобы не мешать тёплое с мягким.
Ну а по поводу анимации - это не опять же не придирка. Одна из главных проблем модалок/попапов - когда их может быть не одна, нужно грамотно ждать пока закроется одно прежде чем открывать другое. Хранить состояние диалогового окна в ячейке стора, как это показано в примере статьи - тут много ума не надо, это может сделать любой за 5 минут
Всё начинает идти не так с описания шага 1. ModalNames у нас какого-то лешего с большой буквы, хотя это не тип, и даже не енум, и уж тем более не класс.
"Строгая типизация обеспечивает дополнительную уверенность и удобство" - нет, она не работает в рантайме. Тайпскрипт никак не запретит вызвать второе окно когда открыто первое.
Ключи в объекте, задаваемые через манипуляцию со строками, и функция capitalizeFirstLetter - это что вообще за нафиг??
По функционалу - конечно же эта приблуда не дружит с анимациями исчезновения, это можно заметить даже визуально когда пропадает попап с данными (остаются названия полей, а значений нет) и layout shift может быть гораздо больше если там картинка какая или большой текст. А если в одном попапе юзер нажмёт условное "да", а скажем средств не хватает и юзеру нужно показать ошибку? Где закрытие одного (ждем анимацию) и только потом открытие следующего?
И вишенка на торте - это ни разу не модалка а попап. А бизнесу может быть надо функционал именно модалки, что её не закроешь пока допустим юзер не тыкнет "да согласен".
Пример с useToggle учит плохому - useCallback ни разу не бесплатный хук, и чтобы сохранить ссылку на функцию в данном случае гораздо лучше использовать useRef
Я вот корпоративную почту читаю примерно никогда. Потому что в мессенджер написать и ответить в 10 раз быстрее. Если срочный вопрос - пишешь в личку и спрашиваешь, случаев что проигнорили было около 0%.
И сложилось такое впечатление, что автор борется с системой в лице некоторых людей и всеми силами старается их победить. А не надо пытаться никого победить, надо работать с людьми. Не надо быть злобной тёткой, которая заваливает всех письмами с постоянным дёрганьем руководителей и красным текстом капсом - это корпкультура явно не айти компании, а бухгалтерии постсоветском завода в худшем смысле.
Ты чё с ума сошёл, 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 - так и просится картинка со слонопингвином с ковчега. А главное непонятно зачем?
Шото я не понял: каким макаром в примере с (false && person.foo)() не будет ошибки, а false && peson.foo() будет какой-то this ?
Интерпретатор увидит false && и вообще не будет исполнять правую часть, а сразу отдаст результат false - разве нет?
Пример с useToggle учит плохому - useCallback ни разу не бесплатный хук, и чтобы сохранить ссылку на функцию в данном случае гораздо лучше использовать useRef
Я вот корпоративную почту читаю примерно никогда. Потому что в мессенджер написать и ответить в 10 раз быстрее. Если срочный вопрос - пишешь в личку и спрашиваешь, случаев что проигнорили было около 0%.
И сложилось такое впечатление, что автор борется с системой в лице некоторых людей и всеми силами старается их победить. А не надо пытаться никого победить, надо работать с людьми. Не надо быть злобной тёткой, которая заваливает всех письмами с постоянным дёрганьем руководителей и красным текстом капсом - это корпкультура явно не айти компании, а бухгалтерии постсоветском завода в худшем смысле.