Lightning Web Components (LWC) の共同作成者で、SalesforceのプリンシパルアーキテクトであるDiego Ferreiro Val氏は、WebComponentsSFで、エンタープライズ規模でWebコンポーネントを活用するプラットフォームを構築する際の課題と教訓について講演した。欠けたところはあるが、Webコンポーネント標準は、Salesforceの相互運用性、後方互換性および上位互換性の目標を大規模に達成するのに役立った。
Ferreiro氏は、Salesforceの特定の制約を提示することから始めた。他のサービスの中でも、Salesforceは、顧客が独自のエンタープライズアプリケーションを実装するためのプラットフォームを販売しているため、完全にカスタマイズ可能である必要がある。したがって、顧客は独自のコンポーネント、オブジェクト、およびユーザインターフェイスを作成できます。Ferreiro氏は、プラットフォームに関する次のビジネス要件を引用した:
- 複数の作者、
- 複数のバージョン、
- 無期限の下位互換性、
- アクセスのしやすさ、
- パーソナライズのしやすさ、
- ローカライズのしやすさ、
- セキュア、
- パフォーマンス (古いブラウザを含む)
3番目の要件は、Salesforceのコンテキストで特に意味がある。Ferreiro氏は強調した:
お客様が今日コンポーネントを作成する場合、それは今後10年間機能する必要があります。
Salesforceには、3年前にゼロから始める機会があり、制約を満たしながら目的を達成するために利用可能なオプションを探した。開発者は、プロプライエタリテクノロジーから離れ、SalesforceまたはAdobeを無差別に使用し、移転可能なスキルを習得し、特定のテクノロジーに縛られることなく、標準のツールを活用できる共通のコンポーネントモデルを好んだ。
Salesforceは、既存のフロントエンドフレームワークとの数か月にわたる調査と議論の結果、以前のコンテンツを壊すことなくWebプラットフォームが進化したことを確認した。したがって、Salesforceは、将来に耐える最善の方法は、可能な限り標準に準拠することであり、最善のオプションはWebコンポーネントに依存することであると結論付けた。Ferreiro氏はコメントした:
この結論に到達するのにしばらく時間がかかりましたが、それは私たちが構築しているものの中核のようなものです。
ただし、Ferreiro氏は、Webコンポーネント標準が低レベルでSaleforceの顧客に直接公開できないAPIを提供していることを確認し、その上に独自のシンタックスシュガーを追加することにした。その作業の結果、Lightning Web Componentsフレームワーク (LWC) はより優れた人間工学を追加し、アクセシビリティ、パフォーマンス、およびブラウザの互換性のギャップを埋めた。コードの例は次のとおりである:
<template>
<p>Counter: {count}</p>
<button onclick={increaseCounter}>Add</button>
</template>
import { LightningElement, track } from "lwc";
export default class MyCounter extends LightningElement {
@track count = 0;
increaseCounter() {
this.count += 1;
}
}
Webコンポーネントの採用はIE11のサポートとShadow DOMのカプセル化という、2つの課題が特に重要であり、困難であることが判明した。2019年9月の時点でIE11はトラフィックの43％に達していたため、IE11のサポートは非常に重要であり続けていた。
したがって、古いブラウザでWebコンポーネントをサポートすることは、エンタープライズソフトウェアの要件である。これは、ポリフィルとbabelプラグインを使用してES5をES7に移行することを意味する。Ferreiro氏は、チームがIE11サポートの実装に数か月を費やし、既存のポリフィルの多くのバグを修正し、パフォーマンス上の理由からアドホックbabelプラグインに頼り、IE11のプロキシサポートを最初に実装したことを強調した。IE11で十分なパフォーマンスを発揮する方法でShadow DOMおよびCSS変数をエミュレートすることは、もう1つの課題だった。イベントのリターゲティング、フォーカス、タブも同様だった。それほど重要なことではなかったが、チームはSeleniumを修正する必要があり、IE11 Seleniumドライバのメンテナになった。チームはまた、JSDOMにWebコンポーネントのサポートを追加し、SafariやChromeなどの他のブラウザで発生した他のいくつかの問題を修正した。
Shadow DOMのカプセル化は、テストとスタイリングの方法を変更することを意味した。カプセル化されたDOMにアクセスするためにシャドウルートをトラバースすることは、何千ものテストを書き直すことを意味した。Ferreiro氏はこの取り組みを苦痛だと説明したが、その結果、コンポーネントとテストの信頼性、回復力、拡張性が向上したとも述べた。ポジティブなニュースとして、一部のテストフレームワークの実装は何らかの形のシャドウセレクター抽象化があり、Selenium WebDriverにはまもなくシャドウピアスプリミティブが追加される。
Shadow DOMスタイルのカスタマイズは、スタイルのカプセル化が改善されたとしても、まだ進行中の問題である。Ferreiro氏は、カスタムプロパティ、::part、:state() などの進行中の仕様により、スタイルのカスタマイズのユースケースの90％が解決されると考えている。CSS Shadowパーツ仕様はまだドラフト段階にあるが、ChromeとFirefoxの両方にすでに実装されている。構築可能なスタイルシートは、制御された方法でコンポーネントのブループリントをさらに制御するのにも役立つ。
Ferreiro氏は、プロダクション環境への道は困難だったが、WebコンポーネントがSalesforceの拡張に役立っていると結論付けた。Salesforce CRMアプリケーションのページには、通常8,000を超えるコンポーネントが含まれている。Salesforceは500万人の開発者を数え、100万人が作成したコンポーネントを数える。Salesforce開発者の73％がLWCを使用しており、Salesforce開発者の95％がWebコンポーネントが正しい方向であると感じている。Webコンポーネントの標準は完成していないが、Ferreiro氏は将来が明るいと信じており、SalesforceがWebプラットフォームを前進させ続け、W3CおよびTC39委員会でエンタープライズユースケースを代表することを示唆している。
Salesforce.com, Inc. は、カスタマリレーションシップマネジメントサービスを提供し、顧客サービス、マーケティングオートメーション、分析、およびアプリケーション開発に焦点を当てたエンタープライズアプリケーションの補完的なスイートを販売するクラウドベースのソフトウェア会社である。
Lightning Webコンポーネントは、MITオープンソースライセンスの下で利用できる。LWCのRFCは、専用のWebサイトからアクセスできる。貢献とフィードバックは大歓迎であり、GitHubプロジェクトを介して提供されるだろう。