Именно. В свое время отказался от красивого синтаксиса 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