Вместо этого используйте веб-компоненты!
Предполагая, что вы читаете эту статью по собственной воле, высока вероятность того, что вы использовали какой-либо материальный дизайн-фреймворк. Их много: Angular Material для Angular, Vuetify для VueJs, Material UI для React и многое другое. Один может быть немного лучше другого. Тем не менее, они предоставляют в основном одни и те же многократно используемые компоненты пользовательского интерфейса, такие как кнопки, элементы ввода, диалоговые окна и т. д. Разве не было бы неплохо использовать компоненты внешнего интерфейса в единой сети, сделав их функциональными во всех фреймворках?
В этой статье я хотел бы показать вам, как веб-компоненты могут упростить и улучшить всемирную паутину, заменив компонентный уровень веб-приложений собственным и унифицированным решением. Наличие взаимозаменяемых, многократно используемых интерфейсных компонентов, основанных на официальных веб-стандартах, может значительно снизить затраты на переход между интерфейсными фреймворками. Таким образом, компании могли бы сэкономить кучу денег, если бы они с самого начала полагались на единообразное и стандартизированное решение для библиотек компонентов.
Что такое веб-компоненты?
Веб-компоненты — это повторно используемые клиентские компоненты, основанные на официальных веб-стандартах и поддерживаемые всеми основными браузерами. Это отличный способ изолироватьфункциональность от остального кода. Кроме того, вы можете повторно использовать их в каждом веб-приложении и веб-странице.
Основное преимущество веб-компонентов заключается в том, что мы можем использовать их везде. С любым фреймворком, или даже без фреймворка. — vuejs.org
Как они работают?
Вот пример определения автономного веб-компонента:
class MyWebComponent extends HTMLElement {...}
window.customElements.define('my-button', MyWebComponent);
Вы можете передать свой элемент на любую HTML-страницу следующим образом:
<my-button value="something"></my-button>
Если вы хотите поиграть с веб-компонентами, вот стартовый код Hello World CodePen. Подробнее о веб-компонентах читайте в других моих статьях:
Стоимость привязки к поставщику
Чтобы понять, почему переход на стандартизированное решение для библиотек компонентов может сэкономить время и деньги, нам нужно понять проблему привязки к поставщику.
Привязка к поставщику – это ситуация, когда стоимость перехода к другому поставщику настолько высока, что вы, по сути, остаетесь с первоначальным поставщиком.
Представьте себе компанию, которая разработала очень сложное веб-приложение с использованием React. Несколько сотен разработчиков работают над ним на постоянной основе. Они создали собственную внутреннюю библиотеку компонентов React. Это помогает свести к минимуму дублирование кода внутри системы, и это прекрасно!
Как мы все знаем, индустрия программного обеспечения — одна из самых быстрорастущих и меняющихся отраслей. Это сопровождается многими изменениями и нововведениями в программной инженерии. Предположим, что в следующем году кто-то выпустит окончательный интерфейсный фреймворк, который затмит любой существующий.
Все больше и больше разработчиков переходят на новый фреймворк. С годами компании будут использовать фреймворк для новых проектов, а некоторые будут переносить существующие. React больше не будет эффективным, а найти хороших разработчиков React становится все сложнее и дороже.
Привязка к поставщику — это когда кто-то фактически вынужден продолжать пользоваться продуктом или услугой вне зависимости от качества — cloudflare.com
Компания в нашем примере будет привязана к младшей внешней библиотеке React. Переход на новую структуру будет очень дорогим и может привести к прерыванию бизнес-операций. Каждый компонент внешнего интерфейса приложения должен быть перенесен в новую структуру. И что еще хуже, каждое приложение, использующее эти компоненты, должно изменить интеграцию своих кнопок, ссылок, диалогов и т. д.
Как разработчик, вы можете свободно использовать React в своих веб-компонентах, использовать веб-компоненты в React или и то, и другое — reactjs.org
Надеюсь, стало ясно, что использование веб-компонентов могло бы сэкономить много денег для нашей компании. Даже сам React предлагает использовать веб-компоненты в своей официальной документации:
Большинство людей, которые используют React, не используют веб-компоненты, но вы можете захотеть, особенно если вы используете сторонние компоненты пользовательского интерфейса, написанные с использованием веб-компонентов. — reactjs.org
Библиотеки компонентов для веб-компонентов
Разработка библиотеки компонентов — непростая задача. Это влечет за собой длинный список решений, которые могут стать весьма подавляющими. К счастью, нам не нужно начинать с нуля. Уже существует несколько библиотек веб-компонентов, поддерживаемых такими компаниями, как, например, Google и SAP:
- Материальные веб-компоненты (MWC): Коллекция веб-компонентов, соответствующих принципам материального дизайна Google.
- Polymer Elements: библиотека Polymer от Google позволяет создавать инкапсулированные многоразовые веб-компоненты, которые работают как стандартные элементы HTML.
- Веб-компоненты Vaadin: Компоненты Vaadin — это развивающийся набор высококачественных веб-компонентов пользовательского интерфейса.
- OpenUI5:богатый набор многоразовых элементов пользовательского интерфейса SAP корпоративного уровня на основе облегченной платформы.
К сожалению, я думаю, что эти компоненты не такие зрелые, как, например, пользовательский интерфейс React Material. Но, чем больше разработчиков будут этому способствовать, тем лучше будет.
Последние мысли
Использование веб-компонентов в качестве основы для библиотек компонентов обеспечивает правильное решение для широкого спектра прогнозируемых и непредвиденных вариантов использования. Веб-стандарты делают наше внешнее приложение более устойчивым к изменениям и могут предотвратить привязку компаний к поставщику. Это может сэкономить много денег.
Я хочу подчеркнуть, что я не предлагаю полностью заменить интерфейсные фреймворки веб-компонентами. Я подробно обсуждал это в одной из моих предыдущих статей Заменят ли веб-компоненты интерфейсные фреймворки?. Мое мнение, что они не скоро заменят фронтенд-фреймворки. Тем не менее, они могут улучшить эти платформы, заменив уровень своих компонентов собственным и унифицированным решением.
Надеюсь, вам понравилось читать эту статью. Каково ваше мнение о веб-компонентах? Не стесняйтесь оставлять комментарий. Я всегда рад ответить на вопросы и открыт для критики. Свяжитесь со мной в любое время 😊
Вот ссылка для неограниченного доступа ко всему контенту здесь, на Medium.Если вы зарегистрируетесь по этой ссылке, я заработаю небольшую сумму без каких-либо дополнительных затрат для вас.
Подписывайтесь на меня, чтобы не пропустить мои следующие статьи. Я пишу о Typescript, веб-компонентах, интерфейсных фреймворках, шаблонах проектирования программного обеспечения, расширениях Chrome и многих других темах! 🙏
Об авторе
Мариус Бонгартс — аналитик по разработке программного обеспечения в Accenture Interactive. Он также создал расширение Web Highlights Chrome Extension, позволяющее тысячам пользователей выделять текст и закладки на каждом веб-сайте. Предоставление тегов и каталогов позволяет вам легко повторно найти свое веб-исследование в соответствующем веб-приложении на web-highlights.com. Проверьте это!
Свяжитесь со мной через LinkedIn или подпишитесь на меня в Twitter.
Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Посетите наш Community Discord и присоединитесь к нашему Коллективу талантов.
