Именно. В свое время отказался от красивого синтаксиса dot нотаций, когда одна из подобных фич грузила дополнительную библиотеку. Например, в такой карточке (а она может быть одна на всю страницу) нужно отобразить график.
А здесь начинает ломаться tree-shaking. И даже если мы будем использовать такой компонент без графика (дополнительной библиотекой), она притащится вся и целиком, даже если не используется, получается мертвый код налицо.
Если же вместе с dot-нотацией идет в комплекте babel-плагин, тогда уже лучше.
А как по-вашему, браузер хранит их? Собственным механизмом разметки бинарного пространства, предоставленном физическим носителем? Нет, это все лежит в файле того или иного формата. В процессе работы -- в оперативной памяти, а затем сохраняет в файл.
Возражу, в таком смысле можно было бы сконфигурировать webpack на генерацию статических svg, со свойствами fill="currentColor" и т.д., и не иметь оверхеда.
Автоматический бандлинг имеет смысл, так как на среднем проекте очень часто используется максимум 5-10-20 общих иконок (стрелочки, человечки, т.д.), если у вас на проекте сотни разных иконок, то скорее всего, довольно весомая часть из них встречается в одном React-компоненте, который и стоит отправлять в отдельный чанк, возможно, с целом куском UI-я, который окружает эту иконку.
Конечно, при бесконечном большом проекте, конечно, бесконечное число иконок будет иметь смысл превратить в бесконечное число мини-чанков, однако в таком крайнем случае просто svg-иконки как svg-файлы будут самым верным решением.
Хорошая статья для понимания того как работает процесс бандлинга. Однако, оверхед в 1,5мб довольно высок, и многие фреймворки имеют автоматическое создание чанков по страницам, компонентам, где оверхед чанка уже незаметен.
Зачем? на работу/учебу и обратно. Я предпочту припарковать и зарядить, чем тащить с собой еще 5кг-10кг батарей. Не хочу переплачивать за ненужный функционал, которы мне вредит.
Должен быстро заряжаться до полной емкости
Тут либо первое, либо второе. Но с этим пунктом я согласен. Однако, время заряда небольшой батарее будет меньше, чем батареи большей емкости.
Не должен бояться заморозков.
Согласен. Возможно, в модели для северных регионов. Не хочу переплачивать за ненужный функционал.
Должен быть более «тяговитым»
Зачем? Чтобы убиться?
Должен быть безопасным
Согласен. Тогда он должен быть легким и не-«тяговитым»
должен продаваться по цене, доступной российскому покупателю.
Делим на ноль.
И с таким подходом про самокат у авторов получается Батут Рогозина.
Дизайн-система — это UI kit, превращенный в код и связанный с ним, т. е. это система [UI kit] [+] [код].
Т. е. UI kit ≠ дизайн-система!
Не уверен, насчет определений, однако согласен с утверждением, о неравенстве.
В моем понимании:
Дизайн-система -- это набор правил и консистентность в цветах, отступах, комбинациях. Грубо говоря, когда говорят "У нас есть Дизайн-система", подразумевают наличие (или желание) имплементированной логики базовых элементов дизайна.
UI-kit -- это набор компонентов, которые могут следовать дизайн-системе. Однако, этот kit может быть имплементирован где угодно: в коде, графическом редакторе. В отличие от дизайн-системы -- UI-kit, это готовый к использованию набор элементов.
Цифра здесь скорее всего с потолка, однако, потерянное время на код-ревью может быть существенным. А одинаковость кода уменьшает когнитивную нагрузку. А этот фактор имеет долговременный эффект.
Будет горизонтальный скролл страницы на iOs, если не прикрыть overflow: hidden; , который может обрезать тени, вызвать дополнительные визуальные баги или отсутствие работы backdropFilter.
А еще проблемы с width: 100%; или необходимость calc()
Да, вот что меня действительно раздражает, так этот момент, когда компонент написан, но тут возникает задача пробросить ref, и начинается синтаксический ад с forwardRef и Typescript. Пока все скобочки в нужном порядке расставишь, все желание кодить пропадает =)
Но по идее мы можем глобально расширить тип HTMLAttributes, либо же создать новый тип-дженерик, который принимал бы на вход параметры для data-атрибутов.
Вот пример (может кому пригодится), с глобальной модификацией:
Одно время я тоже ими пользовался, даже перевел статью про выход пятой версии. Однако, не очень гладкая интеграция с Mui четвертой версии заставила перейти на JSS объектный синтаксис. А сейчас, в пятой версии этой великолепной библиотеки, разработчики взяли emotion как решение по умолчанию.
Возможно, стоит задуматься о возврате к простому kebab-case синтаксису css без upperCase девиаций =)
Что мы действительно (не)знаем о наличии сознания у сверхбольших нейросетей?
Мне кажется, но вы спорите с нейросетью =)
P.S.: Отвечаю ли я нейросети?
P.P.S.: Нейросеть ли я?
Организация react-компонентов с помощью dot-notation и почему я часто прибегаю именно к этому способу
Именно. В свое время отказался от красивого синтаксиса
dotнотаций, когда одна из подобных фич грузила дополнительную библиотеку. Например, в такой карточке (а она может быть одна на всю страницу) нужно отобразить график.А здесь начинает ломаться tree-shaking. И даже если мы будем использовать такой компонент без графика (дополнительной библиотекой), она притащится вся и целиком, даже если не используется, получается мертвый код налицо.
Если же вместе с dot-нотацией идет в комплекте
babel-плагин, тогда уже лучше.Что нужно знать о cookies-файлах, чтобы не нарушить закон?
А как по-вашему, браузер хранит их? Собственным механизмом разметки бинарного пространства, предоставленном физическим носителем? Нет, это все лежит в файле того или иного формата. В процессе работы -- в оперативной памяти, а затем сохраняет в файл.
Оптимизация загрузки js бандла использующего icon pack’и
Возражу, в таком смысле можно было бы сконфигурировать webpack на генерацию статических svg, со свойствами
fill="currentColor"и т.д., и не иметь оверхеда.Автоматический бандлинг имеет смысл, так как на среднем проекте очень часто используется максимум 5-10-20 общих иконок (стрелочки, человечки, т.д.), если у вас на проекте сотни разных иконок, то скорее всего, довольно весомая часть из них встречается в одном React-компоненте, который и стоит отправлять в отдельный чанк, возможно, с целом куском UI-я, который окружает эту иконку.
Конечно, при бесконечном большом проекте, конечно, бесконечное число иконок будет иметь смысл превратить в бесконечное число мини-чанков, однако в таком крайнем случае просто
svg-иконки какsvg-файлы будут самым верным решением.Оптимизация загрузки js бандла использующего icon pack’и
Хорошая статья для понимания того как работает процесс бандлинга. Однако, оверхед в 1,5мб довольно высок, и многие фреймворки имеют автоматическое создание чанков по страницам, компонентам, где оверхед чанка уже незаметен.
Как мы создали российский электросамокат, который на порядок лучше китайских аналогов
Зачем? на работу/учебу и обратно. Я предпочту припарковать и зарядить, чем тащить с собой еще 5кг-10кг батарей. Не хочу переплачивать за ненужный функционал, которы мне вредит.
Тут либо первое, либо второе. Но с этим пунктом я согласен. Однако, время заряда небольшой батарее будет меньше, чем батареи большей емкости.
Согласен. Возможно, в модели для северных регионов. Не хочу переплачивать за ненужный функционал.
Зачем? Чтобы убиться?
Согласен. Тогда он должен быть легким и не-«тяговитым»
Делим на ноль.
И с таким подходом про самокат у авторов получается Батут Рогозина.
React hooks, как не выстрелить себе в ноги. Часть 1: работа с состоянием
Но... mobx рекомендовано использовать с хуками =)
GPT-4 уже не за горами. Что мы о нём знаем
> чему он там "научится"
самому главному -- человеческой натуре
А книги -- это цензурированное и отфильтрованное проявление культуры в довольно узком спектре
Португалия, Кипр, Нидерланды. 3 простые истории поиска работы с релокейтом
А вы правда не видите связи между ламповостью, уменьшением количества интересных статей и отъездом специалистов?
Зубной налет, что это и откуда он берется
А можно все то же самое, но завернуть все картинки под спойлер?
Как мы создавали UI Kit: все о стилизации комплексных React-компонентов
Могу порекомендовать к чтению эту статью https://habr.com/ru/post/649381/
Особенно актуально в UI-kit'ах
Ещё одна статья про дизайн-системы (в продуктовом дизайне)
Не уверен, насчет определений, однако согласен с утверждением, о неравенстве.
В моем понимании:
Дизайн-система -- это набор правил и консистентность в цветах, отступах, комбинациях. Грубо говоря, когда говорят "У нас есть Дизайн-система", подразумевают наличие (или желание) имплементированной логики базовых элементов дизайна.
UI-kit -- это набор компонентов, которые могут следовать дизайн-системе. Однако, этот kit может быть имплементирован где угодно: в коде, графическом редакторе. В отличие от дизайн-системы -- UI-kit, это готовый к использованию набор элементов.
Как ESLint анализирует код и борется с Legacy
Цифра здесь скорее всего с потолка, однако, потерянное время на код-ревью может быть существенным. А одинаковость кода уменьшает когнитивную нагрузку. А этот фактор имеет долговременный эффект.
Простой и эффектный parallax-эффект без JavaScript
Будет горизонтальный скролл страницы на iOs, если не прикрыть
overflow: hidden;, который может обрезать тени, вызвать дополнительные визуальные баги или отсутствие работыbackdropFilter.А еще проблемы с
width: 100%;или необходимостьcalc()Учимся правильно писать CSS классы в JSX
Да, вот что меня действительно раздражает, так этот момент, когда компонент написан, но тут возникает задача пробросить ref, и начинается синтаксический ад с forwardRef и Typescript. Пока все скобочки в нужном порядке расставишь, все желание кодить пропадает =)
Учимся правильно писать CSS классы в JSX
Но по идее мы можем глобально расширить тип HTMLAttributes, либо же создать новый тип-дженерик, который принимал бы на вход параметры для data-атрибутов.
Вот пример (может кому пригодится), с глобальной модификацией:
Учимся правильно писать CSS классы в JSX
Одно время я тоже ими пользовался, даже перевел статью про выход пятой версии. Однако, не очень гладкая интеграция с Mui четвертой версии заставила перейти на JSS объектный синтаксис. А сейчас, в пятой версии этой великолепной библиотеки, разработчики взяли emotion как решение по умолчанию.
Возможно, стоит задуматься о возврате к простому kebab-case синтаксису css без upperCase девиаций =)
Учимся правильно писать CSS классы в JSX
Действительно. Полезная штуковина тогда. Было бы здорово иметь этот функционал встроенным в Реакт
Учимся правильно писать CSS классы в JSX
А в чем "нормально построить строку" внутри
computedбудет фундаментально отличаться от приведенных выше примеров?Не могли бы вы привести пример того, как вы бы использовали
computedв случае приведенного примера из статьи?Учимся правильно писать CSS классы в JSX
Все верно. И я так использовал во времена, когда прямой доступ к DOM был поведением по умолчанию, а Virtual DOM еще не популяризировали.
Свойство
HTMLElement.datasetвызывало чувства красоты, удобства и каноничности.Я был удивлен, когда в React и JSX не оказалось инструмента работы с этим API. Было бы здорово иметь
datasetнаряду сstateиprops