Почему мы выбрали WebComponents для нашей системы проектирования

Я работал над библиотекой пользовательского интерфейса для внутренней системы проектирования в крупной компании (10’000+ сотрудников). Я хочу рассказать о том, почему я выступаю за Web-компоненты.

Контекст

Меня попросили помочь в создании UI Kit на основе Angular, который содержит наши часто используемые компоненты, такие как входы, кнопки и так далее.
В самом начале я сомневался в этом решении. Оно было обосновано тем, что большинство продуктовых команд используют Angular.

Однако, как я выяснил позже, это не всегда так. В Швейцарии, где я нахожусь, действительно большинство команд использовали Angular (возможно, потому, что он казался более естественным для разработчиков на C#, который был доминирующим языком бэкенда). Хотя чем больше я пытался провести «исследование рынка» (=опросить команды внутри компании), тем больше понимал, что, например, в Испании, Польше и США React явно доминирует. В то время как в азиатских странах Vue был основным фронтенд-фреймворком. Мы также работали с внешними компаниями, которые иногда использовали совершенно другие фреймворки. Я понял, что практически все фреймворки, которые вы можете себе представить, все еще используются — от Backbone.js до Svelte.

Поэтому для меня создание библиотеки пользовательского интерфейса с помощью Angular не соответствовало моему видению; мне нужен один UI Kit, который можно использовать в компании. Неважно, какой фреймворк вы используете.

Что, черт возьми, такое веб-компоненты?

Долгое время я искренне не понимал, что такое «веб-компоненты». И по сей день я считаю, что «веб-компоненты» — это просто маркетинговый термин или «синтаксический сахар».
для различных наборов спецификаций HTML.

Позвольте мне разложить эти спецификации по полочкам:

Пользовательские элементы Спецификация Custom Elements закладывает основу для разработки и использования новых типов элементов DOM.
Теневой DOM Спецификация теневого DOM определяет, как использовать инкапсулированный стиль и разметку в веб-компонентах.
Модули ES Спецификация ES Modules определяет включение и повторное использование JS-документов на основе стандартов, модульно и с высокой производительностью.
Шаблон HTML Спецификация элементов шаблона HTML определяет, как объявлять фрагменты разметки, которые не используются при загрузке страницы, но могут быть созданы позже во время выполнения.

Таблица выше была взята с сайта webcomponents.org

В двух словах Web Components — это термин, объединяющий все эти спецификации.

Зачем нужны веб-компоненты

Теперь, когда мы понимаем, что такое веб-компоненты, я хочу проанализировать, как это может нам помочь, учитывая контекст, в котором я находился.

Теневой DOM и пользовательские свойства

Shadow DOM по сути инкапсулирует CSS и HTML. Причина, по которой это действительно полезно, заключается в том, что у вас есть больше контроля над тем, что считается публичным и приватным API компонента.

Чтобы объяснить это дальше, давайте посмотрим, как, вероятно, большинство людей использовали библиотеки пользовательского интерфейса, такие как Bootstrap, в старые добрые времена.

Обычно вы копировали/вставляли HTML-блок, а иногда и импортировали JavaScript, когда хотели использовать компонент. Часто вы также настраивали HTML с помощью дополнительного кода CSS, чтобы он выглядел более соответствующим вашему брендингу.

Теперь представьте, что Bootstrap внесет некоторые изменения в CSS компонента. Поскольку любой имеет полный доступ к перезаписи любого CSS компонента Bootstrap, обновление до последней версии Bootstrap может привести к неприятным побочным эффектам. Со стороны Bootstraps нет никакого контроля над тем, как будут использоваться и изменяться компоненты.

Для такой библиотеки, как Bootstrap, это может быть не очень важно, но в библиотеке пользовательского интерфейса Design Systems вы хотите максимально консолидировать компоненты и разрешить изменять только определенные вещи.

Теперь с помощью Shadow DOM и спецификаций Custom Properties вы можете полностью инкапсулировать HTML и CSS компонента, но при этом позволить настраивать его с помощью Custom CSS Properties. Таким образом, это означает, что API ваших компонентов гораздо более явный и не все является общедоступным.

Это дает гораздо больше здравомыслия авторам библиотек UI Kits, а также позволяет использовать SemVer гораздо более здраво, поскольку вы точно знаете, когда API компонентов считается нарушенным (например, удаление пользовательского свойства). Это делает обновление вашей библиотеки гораздо более предсказуемым (учитывая, что они не пробивали Shadow DOM).

Агностичность фреймворка

Одной из наших самых больших проблем было обслуживание команд с очень разными технологическими стеками. Хотя это вполне реальный и хороший вариант — просто использовать ванильные HTML, CSS и JS без веб-компонентов для вашего UI Kit, я считаю, что опыт разработчиков пострадает. Кроме того, вы не сможете предотвратить использование частных API компонентов, как упоминалось выше.

В целом, Web-компоненты достаточно хорошо поддерживаются большинством фреймворков.

Однако есть одна большая оговорка: React v18 не поддерживает работу с богатыми данными или обработку событий веб-компонентов.

Источник: custom-elements-everywhere.com

В React v19 эта проблема должна быть решена, но на момент написания статьи она не является стабильной для
производственного использования.

Поэтому, кроме React, вы должны иметь возможность использовать веб-компоненты (включая Preact) — хотя позже в этой статье я подробнее расскажу, как можно обойти это ограничение, а также поддержать JSX как гражданина первого класса.

Недостатки веб-компонентов и способы их устранения

Написание веб-компонента с использованием только ванильного JS является громоздким. Нужно добавить много кода, чтобы сделать простейшие вещи, которые вы обычно ожидаете от таких фреймворков, как Vue, Angular или React.

В природе разработчиков просто сокращать избыточный код и абстрагировать низкоуровневые интерфейсы. К сожалению, это, скорее всего, приведет к созданию своего рода Франкенштейна-фреймворка, который, скорее всего, не будет даже наполовину так хорош, как другие уже существующие фреймворки, и, возможно, даже не будет документирован. Поэтому я пришел к выводу, что веб-компоненты не заменят ваш фронтенд-фреймворк.

К счастью, уже существует несколько замечательных библиотек и фреймворков. Например:

  • Lit
  • Stencil
  • Hybrids
  • Slim.JS

Эти фреймворки, конечно, имеют некоторые существенные различия в философии, реализации и стиле. Мы остановили свой выбор на Stencil.

Stencil

Stencil — это набор инструментов для создания многократно используемых, масштабируемых систем проектирования. Создавайте небольшие, молниеносные и на 100% основанные на стандартах веб-компоненты, которые работают в любом браузере.

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

Компилятор

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

TypeScript

Это мое мнение, но мне очень нравится, что Stencil полностью поддерживает TypeScript. До такой степени, что он даже использует TypeScript reflection API для автоматической генерации документации в формате Markdown. Например, все ваши события и реквизиты будут автоматически документированы с правильной типизацией.
Это действительно полезно, потому что если вы создаете UI Kit, то документация будет абсолютно необходимой. Хотя это
это не полностью устраняет необходимость в документации, по крайней мере, вам не нужно документировать компонент
Атаномия.

На мой взгляд, компонент Stencil берет лучшее из мира Angular и React; феноменальная поддержка TypeScript, а также TSX.

import { Component, Prop, h } from '@stencil/core';

@Component({
  tag: 'my-first-component',
})
export class MyComponent {

  // Indicate that name should be a public property on the component
  @Prop() name: string;

  render() {
    return (
      <p>
        My name is {this.name}
      </p>
    );
  }
}
Вход в полноэкранный режим Выход из полноэкранного режима

Пример компонента Stencil

Привязка к фреймворку

Как я уже говорил, веб-компоненты имеют некоторые ограничения в React. Хотя Stencil действительно предоставляет Framework
привязки, которые, по сути, оборачивают веб-компонент в API компонент целевого фреймворка.

Так, например, если вы используете привязку React Framework, она автоматически создаст компонент React со всеми реквизитами и событиями и соединит их с веб-компонентом. Это возможно благодаря тому, что Stencil активно использует API отражения TypeScript для автоматической генерации этих интеграций.

Это также обеспечивает потрясающий опыт разработчика. Ваш веб-компонент станет почти неотличим от родных компонентов React.

// Without using framework bindings
function MyComponent() {
    return <ui-kit-component></ui-kit-component>
}

// With using framework bindings
import { UiKitComponent } from '@my-ui-kit/react';

function MyComponent() {
    return <UiKitComponent />
}
Вход в полноэкранный режим Выход из полноэкранного режима

Заключение

Для нас веб-компоненты с Stencil до сих пор работали отлично. Кроме того, с помощью Framework Bindings мы можем обеспечить естественный опыт разработчика для разработчиков React, Angular и Vue. Благодаря Shadow DOM и Custom Properties теперь есть гораздо более четкий интерфейс того, что считается публичной и приватной функциональностью
компонента. Это особенно помогает пользователям библиотеки, так что они с меньшей вероятностью могут прострелить себе ногу.
чрезмерно настраивая компоненты UI-Kit.

Вместо того чтобы создавать несколько UI-Kit на Angular, Vue или React, мы можем просто иметь один источник истины и использовать любой фреймворк, какой захотим.

Дальнейшее чтение

Нам еще многое предстоит изучить, когда речь заходит о Design System. Вот несколько дополнительных постов, которые я сделал и которые могут показаться вам интересными.

  • Создание иконочного веб-фронта для вашей Design System
  • Использование трафарета с GatsbyJS
  • Design Tokens @ WebZürich (YouTube)

Оцените статью
Procodings.ru
Добавить комментарий