Comments 17
Мое мнение: практически нет ни одного адекватного кейса, когда пользователь, работая на мобильном устройстве, неожиданно окажется перед полноценным монитором с шириной экрана 1920px.
Ну есть еще смена ориентации, ресайз окна.
Вы же не будете привязываться строго к 1080р?
static get styles() {
const mobileStyle = css`p { color: red; }`;
const desktopStyle = css`p { color: green; }`;
return [
mobileStyle,
desktopStyle
];
}
не забыв добавить медиазапросы к стилям
Основной оверхед от лишних стилей заключается в том, что они увеличивают размер бандла.
А здесь стили все равно загружаются, просто не выводятся в CSS. Есть ли вообще в этом выгода?
По поводу бандла. использовать динамический импорт и нет проблем с объемом
Как мне кажется, браузер сам достаточно умный, чтобы игнорировать неподходящие @media блоки.
У вас есть какое-то подтверждение ускорения после этой оптимизации? Без него это выглядит как призыв экономить на спичках.
Так в статье уточнения про бесполезность этой оптимизации нет, поэтому многие неокрепшие умы могут принять это за руководство к действию.
Именно это и побудило меня оставить коммент
- Из текста «Я не являюсь экспертом в данной технологии», «это дико, но имеет место быть», «Мое мнение». Я не считаю нужным вешать там огромный баннер «не делайте так!», там где высказываю личное мнение. По поводу бесполезности оптимизации, если есть желание, я предлагаю Вам доказать несостоятельность этого подхода. Я высказал свое мнение и в комментах подтверждаю «По идее, это должно повлиять на конечную скорость отрисовки. А по факту, в большинстве случаев — это «экономия на спичках».»
- На этом, считаю, что данная ветка в дальнейшем не актуальна. Если есть желание в дальнейшем подискутировать на эту тему, то велком в личку
использовать динамический импорт и нет проблем с объемом
А вот это интересно. Как можно сделать динамический импорт стилей в lit-element?
Для поддержки абсолютно не рабочий вариант и нужно еще сменить parcel на что то более управляемое, что бы дробил на чанки, но как пример сойдет
У lit-element есть еще интересное св-во updateComplete ( https://lit-element.polymer-project.org/guide/lifecycle#updatecomplete ) — это промис, который резолвится после того, как компонент обновился.
async someAction() {
this.prop = 'new value';
await this.updateComplete;
console.log('update complete');
}Но, это таит в себе подводный камень. В том же реакте, функция componentDidUpdate вызовется только после того, как обновятся все дочерние компоненты ( грубо говоря, сначала у дочерних компонентов вызывается componentDidUpdate, а потом у родительского ), тут это не так и updateComplete не гарантирует, что обновились дочерние элементы. Видимо это из-за специфики веб-компонентов ( shadowRoot и так далее ), поэтому приходится в простых случаях писать так
async someAction() {
this.prop = 'new value';
await this.updateComplete;
await children.updateComplete;
}В более сложных пилить костыли.
Полезная статья, спасибо за труд.
По поводу динамической подгрузки веб-компонентов, можете сказать на сколько большими они у вас получились, что пришлось делать Lazy Loading?
И на сколько, на ваш взгляд, стоит заморачиваться с общим решением для этого? Судя по моему опыту и issue в большинстве случаев при разработке приложений routing и code splitting решает проблему больших бандлов. Помимо него можно воспользоваться динамической загрузкой дочерних компонентов из основного по разного рода хукам (как понимаю, в последнем списке вы один из таки алгоритмов и описываете).
При переработке текущего сайта мы изначально взяли модель ленивой подгрузки логики и стилей для компонентов, на основе вью браузера и динамических импортов, тем самым заложив на будующее основу при которой не придется сильно беспокоиться о размере бандла и кол-ве лишнего кода (по крайней мере, надеемся на это)а так же, возможно поможет при построении микрофронтендов.
В динамическую подгрузку попадают элементы которые предположительно могут быть переиспользованны на сайте независимо от страницы и контекста, компоненты от которых они зависят однозначно импортируются без динамики в ленивые компоненты, далее webpack сам разбивает код на чанки в зависимости от зависимостей для каждго компонента.
При таком подходе, мне на пилотных проектах удавалось достичь общего размера js не более 60кб (учитывая, что там еще и css в этих js) и 1/3 из этого загружалась только тогда, когда пользователь долистывал до футера. А используя http2 протокол мы можем дробить наши компонентики как угодно мелко.
Опять же, нам понадобилась такая система при SSR на java, где «пользователю» предоставлен режим автора и он может на страницу накидать все что угодно и это должно как то работать между собой и не ломаться
Знакомство с lit-element и веб-компонентами на его основе