За последний год команда Polymer потратила много времени на обучение разработчиков созданию собственных элементов. Это привело к быстрому росту экосистемы, в значительной степени поддерживаемой элементами Core и Paper от Polymer, а также элементами Brick, созданными командой Mozilla.
По мере того, как разработчики все больше осваивают создание собственных элементов и начинают задумываться о создании приложений, возникает ряд вопросов:
- Какую структуру пользовательского интерфейса следует использовать в вашем приложении?
- Как вы переходите из одного состояния в другое?
- Каковы стратегии повышения производительности ?
- И как обеспечить офлайн- опыт?
Для Chrome Dev Summit я попытался ответить на эти вопросы, создав небольшое приложение для контактов и проанализировав процесс, который я прошел, чтобы его создать. Вот что у меня получилось:
Структура
Разбиение приложения на модульные части, которые можно объединять и повторно использовать, является центральным элементом веб-компонентов. Элементы Core-* и Paper-* в Polymer позволяют легко начать с небольших частей, таких как paper-toolbar и paper-icon-button .
А с помощью композиции комбинируйте их с любым количеством элементов, чтобы создать каркас приложения.
Как только у вас будет общий каркас, вы можете применить собственные стили CSS, чтобы превратить его в уникальный для вашего бренда опыт. Прелесть использования компонентов в том, что это позволяет вам создавать совершенно разные опыты, используя те же примитивы построения приложений. Имея каркас, вы можете перейти к размышлениям о контенте.
Одним из элементов, который особенно хорошо подходит для работы с большим объемом контента, является core-list .
core-list может быть подключен к источнику данных (по сути, массиву объектов), и для каждого элемента в массиве он будет штамповать экземпляр шаблона. В шаблоне вы можете использовать мощь системы привязки данных Polymer, чтобы быстро подключить ваш контент.
Переходы
После разработки и реализации различных разделов вашего приложения следующей задачей станет выяснение того, как на самом деле перемещаться между ними.
Хотя core-animated-pages все еще является экспериментальным элементом, он предоставляет подключаемую систему анимации, которую можно использовать для перехода между различными состояниями в вашем приложении.
Но анимация — это только половина головоломки: приложению необходимо объединить эти анимации с маршрутизатором, чтобы правильно управлять своими URL-адресами.
В мире веб-компонентов маршрутизация бывает двух видов: императивная и декларативная. Сочетание core-animated-pages с любым из подходов может быть допустимым в зависимости от потребностей вашего проекта.
Императивный маршрутизатор (например, Director компании Flatiron ) может прослушивать соответствующий маршрут, а затем давать команду core-animated-pages обновить выбранный элемент.
Это может быть полезно, если вам нужно выполнить некоторую работу после сопоставления маршрута и до перехода к следующему разделу.
С другой стороны, декларативный маршрутизатор (например, app-router ) может фактически объединить маршрутизацию и core-animated-pages в один элемент, поэтому управление ими становится более рационализированным.
Если вам нужен более детальный контроль, вы можете рассмотреть библиотеку вроде more-routing , которую можно объединить с core-animated-pages с помощью привязки данных и, возможно, получить лучшее из обоих миров.
Производительность
По мере того, как ваше приложение обретает форму, вам следует внимательно следить за узкими местами производительности, особенно за всем, что связано с сетью, поскольку это часто самая медленная часть мобильного веб-приложения.
Легкого выигрыша в производительности можно добиться за счет условной загрузки полифиллов веб-компонентов.
Нет смысла нести все эти расходы, если платформа уже имеет полную поддержку! В каждом выпуске нового репозитория webcomponents.js полифиллы также были разбиты на отдельные файлы. Это полезно, если вы хотите условно загрузить подмножество полифиллов.
<script>
if ('import' in document.createElement('link')) {
// HTML Imports are supported
} else {
document.write(
'<script src="bower_components/webcomponentsjs/HTMLImports.min.js"><\/script>'
);
}
</script>
Также можно получить значительный сетевой выигрыш, выполняя все импорты HTML с помощью такого инструмента, как Vulcanize.
Vulcanize объединит ваши импорты в один пакет, значительно сократив количество HTTP-запросов, которые делает ваше приложение.
Оффлайн
Но просто создание производительного приложения не решает дилемму пользователя с небольшим или отсутствующим подключением. Другими словами, если ваше приложение не работает в автономном режиме, то это не совсем мобильное приложение. Сегодня вы можете использовать сильно критикуемый кэш приложений для офлайн-доступа к вашим ресурсам, но, заглядывая в будущее, Service Worker должен вскоре сделать опыт офлайн-разработки намного приятнее.
Джейк Арчибальд недавно опубликовал потрясающую кулинарную книгу шаблонов для работников сферы услуг, но я дам вам краткий старт, с которого можно начать:
Установка service worker довольно проста. Создайте файл worker.js и зарегистрируйте его при загрузке вашего приложения.
Важно, чтобы вы разместили worker.js в корне вашего приложения, это позволит ему перехватывать запросы из любого пути в вашем приложении.
В обработчике установки рабочего процесса я кэширую массу ресурсов (включая данные, необходимые для работы приложения).
Это позволяет моему приложению предоставлять пользователю по крайней мере резервный вариант, если он получает к нему доступ в автономном режиме.
Вперед!
Веб-компоненты — это большое дополнение к веб-платформе, и они все еще находятся в зачаточном состоянии. По мере того, как они появляются во все большем количестве браузеров, нам, сообществу разработчиков, придется выработать лучшие практики для структурирования наших приложений. Вышеуказанные решения дают нам отправную точку, но еще многое предстоит узнать. Вперед, к созданию лучших приложений!