За прошедший год команда Polymer потратила много времени на обучение разработчиков созданию собственных элементов. Это привело к быстро растущей экосистеме, в значительной степени поддерживаемой элементами Polymer Core и Paper, а также элементами Brick, созданными командой Mozilla.
Когда разработчики лучше знакомятся с созданием собственных элементов и начинают задумываться о создании приложений, возникает ряд вопросов:
- Как следует структурировать пользовательский интерфейс вашего приложения?
- Как вы проходите через разные состояния?
- Каковы стратегии повышения производительности ?
- И как обеспечить офлайн- опыт?
На саммите Chrome Dev Summit я попытался ответить на эти вопросы, создав небольшое приложение для контактов и проанализировав процесс его создания. Вот что я придумал:
Состав
Разбиение приложения на модульные части, которые можно комбинировать и повторно использовать, является центральным элементом веб-компонентов. Элементы Polymer core-* и paper-* позволяют легко начать с небольших частей, таких как paper-toolbar и paper-icon-button .
А благодаря возможностям композиции комбинируйте их с любым количеством элементов, чтобы создать каркас приложения.
Когда у вас есть общий каркас, вы можете применить свои собственные стили CSS, чтобы превратить его в уникальный опыт вашего бренда. Прелесть такого подхода с компонентами в том, что он позволяет создавать совершенно разные впечатления, используя одни и те же примитивы создания приложений. Имея основу, вы можете перейти к обдумыванию контента.
Одним из элементов, который особенно хорошо подходит для работы с большим количеством контента, является core-list .
core-list может быть подключен к источнику данных (по сути, массиву объектов), и для каждого элемента массива он будет создавать экземпляр шаблона. В шаблоне вы можете использовать возможности системы привязки данных Polymer для быстрого подключения вашего контента.
Переходы
После того, как различные разделы вашего приложения разработаны и реализованы, следующая задача — выяснить, как на самом деле перемещаться между ними.
Хотя core-animated-pages все еще является экспериментальным элементом, он предоставляет подключаемую систему анимации, которую можно использовать для перехода между различными состояниями вашего приложения.
Но анимация — это только половина дела: приложению необходимо объединить эту анимацию с маршрутизатором, чтобы правильно управлять своими URL-адресами.
В мире веб-компонентов маршрутизация бывает двух видов: императивная и декларативная. Комбинирование core-animated-pages с любым подходом может быть оправдано в зависимости от потребностей вашего проекта.
Императивный маршрутизатор (например, директор Flatiron ) может прослушивать соответствующий маршрут, а затем давать команду core-animated-pages обновить выбранный элемент.
Это может быть полезно, если вам нужно выполнить некоторую работу после совпадения маршрута и до перехода к следующему разделу.
С другой стороны, декларативный маршрутизатор (например, app-router ) может фактически объединить маршрутизацию и core-animated-pages в один элемент, поэтому управление ими становится более рациональным.
Если вам нужен более детальный контроль, вы можете взглянуть на такую библиотеку, как more-routing , которую можно комбинировать с core-animated-pages с использованием привязки данных и, возможно, дать вам лучшее из обоих миров.
Производительность
По мере формирования вашего приложения вам необходимо внимательно следить за узкими местами в производительности, особенно за всем, что связано с сетью, поскольку зачастую это самая медленная часть мобильного веб-приложения.
Легкий выигрыш в производительности достигается за счет условной загрузки полифилов веб-компонентов.
Нет смысла нести все эти расходы, если платформа уже имеет полную поддержку! В каждом выпуске нового репозитория webcomComponents.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 вскоре должен сделать автономную разработку намного приятнее.
Джейк Арчибальд недавно опубликовал потрясающую кулинарную книгу шаблонов сервисных работников , но я дам вам быстрый старт:
Установить сервис-воркера довольно просто. Создайте файл worker.js и зарегистрируйте его при загрузке приложения.
Важно, чтобы worker.js находился в корне вашего приложения: это позволит ему перехватывать запросы по любому пути в вашем приложении.
В обработчике установки работника я кэширую массу ресурсов (включая данные, которые обеспечивают работу приложения).
Это позволяет моему приложению предоставить пользователю как минимум запасной вариант, если он обращается к нему в автономном режиме.
Вперед!
Веб-компоненты — важное дополнение к веб-платформе, и они все еще находятся в зачаточном состоянии. По мере того, как они появляются во всё большем количестве браузеров, нам, сообществу разработчиков, предстоит определить лучшие практики структурирования наших приложений. Вышеупомянутые решения дают нам отправную точку, но нам еще многое предстоит узнать. Вперед к созданию лучших приложений!