Компоненты по дешевке

Возьми свой торт и съешь его тоже

В моем предыдущем посте Модули ES6 как компоненты я подробно остановился на подходе к разработке на основе компонентов, который мне очень нравится. Короче говоря, вы пишете свой код компонентов в виде модулей ES6. Затем они полностью динамически загружаются в зависимости от потребностей страницы.

В этом посте я хочу объяснить, почему эта концепция настолько эффективна, а также представить новую опцию загрузки, которую я добавил с тех пор: отложенную загрузку на основе положения окна просмотра.

Стоимость компонентов

Поскольку в Интернете на самом деле нет зрелой собственной системы на основе компонентов (работа в процессе), популярным методом является использование фреймворка. Фреймворк имеет определенный размер и затраты на производительность, которые варьируются от нескольких десятков до нескольких сотен КБ. Это первая часть стоимости компонентов.

Затем идет стоимость самих компонентов. Поскольку в большинстве случаев вы будете использовать систему связывания для объединения кода компонента в большие файлы, это означает, что многие из ваших страниц будут загружать код компонента, который не используется. Для этого есть решения, такие как более динамичные формы связывания и встряхивания деревьев. Тем не менее, ими будет сложно управлять, если у вас много шаблонов. А что, если компоненты динамически создаются из пользовательского контента?

Суть часто заключается в том, что размер ваших компонентов и библиотеки компонентов в целом напрямую влияет на производительность многих, если не всех ваших страниц. Следовательно, вас удерживают. От написания слишком большого количества компонентов или от написания слишком причудливых компонентов. Это вторая часть стоимости компонентов.

Часть 3 стоимости компонентов не связана с производительностью. Это связано с инвестициями. Любой самоуверенный компонент, который вы пишете, стоит времени и денег, которых не хватит надолго, поскольку фреймворки приходят и уходят.

Другими словами, компоненты недешевы.

Дешевые компоненты

Чтобы противостоять вышеизложенному, давайте изучим стоимость компонентов, используя подход, который я использую, используя несколько сценариев:

Страница без компонентов

Как бы безумно это ни звучало, в новом интерфейсе, который я создаю для JungleDragon, могут быть страницы вообще без компонентов. Просто содержимое, поступающее с сервера, оформленное с использованием CSS-фреймворка Silva. Чтобы понять, как много можно сделать, используя только HTML и эту структуру CSS, я приглашаю вас изучить демонстрационный сайт:



Вернемся к сути: на страницах с нулевыми компонентами стоимость фреймворка нулевая.

Страница с компонентами

Если на странице есть хотя бы один компонент, ему нужен мой небольшой вспомогательный скрипт (на самом деле это не фреймворк), а также SystemJS. Комбинация составляет ‹ 10 КБ. Таким образом, накладные расходы фреймворка почти нулевые.

Кроме того, стоимость компонентов полностью динамична и зависит исключительно от потребностей страницы. Если я хочу сойти с ума, создавая 10 МБ 3D-фотогалерею на одной странице, это не повлияет ни на одну другую страницу.

Таким образом, вы разблокированы. Вы можете время от времени писать большие компоненты и можете создать библиотеку компонентов из 700 компонентов. У обоих больше нет затрат на общую производительность или накладные расходы. Это просто перестает иметь значение.

Это творческая разблокировка. Открытое приглашение. Сильно отличается от нынешнего клейма «вы не можете сделать это, потому что мобильно, потому что производительность». Конечно, вам по-прежнему необходимо следить за производительностью, но не до такой степени, чтобы каждая написанная вами строка кода влияла на производительность всей вашей системы.

И в-третьих, как объяснялось в моей предыдущей статье, вы будете писать все это, используя модули ES6. Которые работают сегодня, а также через 10 лет.

Стратегии загрузки компонентов

Мы можем пойти даже дешевле, чем это. Давайте рассмотрим способы, которыми этот подход позволяет вам загружать/создавать экземпляр компонента:

Рендеринг на стороне сервера, автоматическая инициализация

В сценарии с визуализацией HTML на стороне сервера все, что вам нужно сделать для загрузки и создания экземпляров компонентов, — это добавить к ним атрибут data-component-init. До безобразия просто. Это позволит динамически загружать нужные модули и создавать из них компоненты для каждого экземпляра в разметке, после чего вы сможете взаимодействовать с ними.

Рендеринг на стороне клиента, ручная инициализация

Вы также можете вручную вставить разметку компонента в DOM, а затем динамически загрузить компонент. С условным созданием экземпляров компонентов на стороне клиента у вас есть полный контроль над тем, что загружается.

Инициализация срабатывает вьюпорте

Это совершенно новый способ загрузки компонентов, который я добавил сегодня. Замечательно загружать только те компоненты, которые необходимы на странице. Еще лучше загружать только те компоненты, которые фактически просматриваются пользователем:

Этот экземпляр компонента Google Map в середине страницы загружается и создается только тогда, когда он попадает в область просмотра пользователя. Если пользователь никогда туда не попадает, он никогда не загружается.

Если вы думаете, что кодировать такой компонент сложно, подумайте еще раз. Все, что вам нужно сделать, это добавить data-component-watch в качестве атрибута в его разметку. Итак, теперь вы можете идти дальше и создавать тупо длинные страницы, так как не просматривается, значит не загружается.

Еще одна интересная особенность этого нового метода заключается в том, что вы можете применять data-component-watch к компонентам, которые также имеют атрибут data-component-init. Эти компоненты будут инициализированы, даже если пользователь никогда их не просматривает (из-за атрибута init), однако атрибут наблюдения по-прежнему добавляет значение. Он будет динамически вызывать события для экземпляра компонента, когда он находится внутри области просмотра и вне области просмотра, позволяя компоненту запускать что-то, когда это происходит, если это необходимо.

Суть в том, что мы загружаем компоненты, написанные в виде модулей ES6, исходя непосредственно из потребностей страницы с почти нулевыми накладными расходами, и мы можем довести это до загрузки только кода, который фактически просматривается. С такими дешевыми компонентами больше нет необходимости сдерживаться.