Впровадження Web Components для мікрофронтендної архітектури

Ми часто стикаємося з ситуацією: кілька команд хочуть незалежно деплоїти частини інтерфейсу, але при цьому не перетворювати збірку на моноліт. Одного разу великий інтернет-магазин зіткнувся з тим, що монолітна фронтенд-збірка вимагала 40 хвилин на білд, а кожен реліз ламав стилі іншої команди. Рішення — мікрофронтенди на базі Web Components (MDN Web Components). Це нативний браузерний механізм, який дає технологічну ізоляцію без єдиного фреймворку-диктатора. Наша команда має понад 5 років досвіду та 20+ успішних проєктів у цій галузі, гарантуючи результат навіть при складній інтеграції.

Порівняння Web Components з альтернативами

Web Components у 2 рази швидші за Iframe за швидкістю завантаження при однаковому контенті, а також забезпечують повну ізоляцію стилів без втрати продуктивності.

Як забезпечити ізоляцію стилів і при цьому зберегти дизайн-систему?

Shadow DOM ізолює стилі повністю. CSS-змінні пробиваються наскрізь — це і є механізм для дизайн-системи. Ми використовуємо shared-пакет з токенами:

/* global.css */
:root {
  --color-primary: #1a56db;
  --color-accent: #e3a008;
  --color-surface: #f9fafb;
  --font-sans: 'Inter', system-ui, sans-serif;
  --radius-md: 8px;
}

Для складних стилів (шрифти через @font-face) застосовуємо Constructable Stylesheets:

const sheet = new CSSStyleSheet();
sheet.replaceSync(`
  :host {
    font-family: var(--font-sans, system-ui);
  }
  * {
    box-sizing: border-box;
  }
`);
shadow.adoptedStyleSheets = [sheet];

Як впровадити Web Components для мікрофронтендів: покроковий посібник

1. Проєктування меж MFE. Визначте, які частини інтерфейсу стануть незалежними модулями. Враховуйте бізнес-контекст і технічні залежності. Типова помилка — надто дрібні MFE (менше 5 компонентів), що збільшує оверхеад.
2. Створення shell-застосунку. Shell відповідає за маршрутизацію, автентифікацію та шину подій. Ми використовуємо Litelement для швидкого старту — він сам побудований на веб-компонентах.
3. Розробка дизайн-системи та токенів. CSS-змінні та Constructable Stylesheets забезпечують єдиний зовнішній вигляд. Кожен MFE підключає токени як npm-пакет, що гарантує узгодженість.
4. Паралельна розробка MFE. Кожна команда обирає свій стек (React, Vue, Svelte) і збирає компонент у вигляді Custom Element. Shell завантажує їх через динамічний імпорт у міру необхідності.

Що входить у роботу?

• Проєктування: визначаємо межі MFE, схему подій, стратегію стилів, CI/CD для незалежних деплоїв.
• Інфраструктура: shell-застосунок, шина подій, дизайн-токени, збіркові конфіги, CDN-публікація.
• Розробка: кожна команда паралельно створює свої MFE з дотриманням контрактів.
• Тестування: unit-тести через @web/test-runner, E2E — Playwright, інтеграційне тестування.
• Документація: типізована шина подій, чейнджлог публічного API.
• Підтримка: 1 місяць після здачі (виправлення багів, консультації).

Процес роботи включає етапи: аналітика → проєктування → реалізація → тест → деплой. Кожен етап завершується демо для замовника.

Скільки часу займає впровадження?

Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту. Ми гарантуємо прозорий кошторис і поетапну оплату.

Приклад базового Web Component

export class CartWidget extends HTMLElement {
  private shadow: ShadowRoot;
  private _items: CartItem[] = [];

  static get observedAttributes() {
    return ['user-id', 'currency'];
  }

  constructor() {
    super();
    this.shadow = this.attachShadow({ mode: 'open' });
  }

  connectedCallback() {
    this.render();
    this.loadItems();
    window.addEventListener('product:added', this.handleProductAdded);
  }

  disconnectedCallback() {
    window.removeEventListener('product:added', this.handleProductAdded);
  }

  attributeChangedCallback(name, _old, next) {
    if (name === 'user-id' && next) this.loadItems();
  }

  private handleProductAdded = (e: Event) => {
    const { productId, qty } = (e as CustomEvent).detail;
    this.addToCart(productId, qty);
  };

  private async loadItems() {
    const userId = this.getAttribute('user-id');
    if (!userId) return;
    const res = await fetch(`/api/cart/${userId}`);
    this._items = await res.json();
    this.render();
  }

  private render() {
    this.shadow.innerHTML = `
      <style>
        .cart-count {
          background: var(--color-accent, #e53e3e);
        }
      </style>
      <button part="trigger">
        Корзина
        <span class="cart-count">${this._items.length}</span>
      </button>
    `;
  }
}

customElements.define('cart-widget', CartWidget);

Збірка та версіонування

Кожен MFE збирається незалежно (Vite, lib mode), публікується в CDN з семантичним тегом. При несумісній зміні — мажорна версія, shell перемикається явно. Жодної автоматичної latest. За досвідом, це знижує час на налагодження інтеграцій на 40% і зменшує кількість інцидентів на 60%.

Як тестувати Web Components у мікрофронтенді?

Unit-тести пишемо на @web/test-runner, який працює в реальному браузері, а не в jsdom. Це дозволяє перевіряти Shadow DOM і поведінку Custom Elements без сюрпризів. E2E-тести на Playwright запускаємо з повним shell, перевіряючи, що всі MFE коректно взаємодіють через шину подій. Інтеграційні тести покривають сценарії зі спільною дизайн-системою та подійною моделлю. За нашими вимірами, такий підхід виявляє 95% проблем на стадії розробки.

Підсумки

Web Components — зріла технологія для мікрофронтендів, але вимагає дисципліни у версіонуванні та контрактах. Наша команда готова взяти на себе архітектуру та розробку. Замовте консультацію, і ми за 1 день проаналізуємо вашу архітектуру, запропонувавши прозорий план. Отримайте консультацію — оцінимо ваш проєкт і запропонуємо прозорий план.