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