Lightning Web コンポーネントへのスタイルとデータの追加

学習の目的

この単元を完了すると、次のことができるようになります。

コンポーネントに CSS と Lightning Design System を使用する。
Salesforce 組織からデータを取得する。
アプリケーションを組織にリリースしてテストする。

メモ

日本語で受講されている方へChallenge は日本語の Trailhead Playground で開始し、日本との値をコピーして貼り付けます。日本語の組織で Challenge が不合格だった場合は、(1) この手順に従って [Locale (地域)] を [United States (米国)] に切り替え、(2) [Language (言語)] を [English (英語)] に切り替えてから、(3) [Check Challenge (Challenge を確認)] ボタンをクリックしてみることをお勧めします。

翻訳版 Trailhead を活用する方法の詳細は、自分の言語の Trailhead バッジを参照してください。

コンポーネントの適応

Lightning Web コンポーネントの概要も残りわずかですが、ここでは、コンポーネントの外観を制御する方法と、ライブデータを取得する方法を試してみましょう。コンポーネントのデザインを Lightning 環境に適応させ、組織のライブデータを取得することができます。この単元では、いくつかのテキストの外観を色鮮やかにし、組織のレコードから動的に名前を描画します。

この単元を完了するには、前の単元の自転車セレクターアプリケーションのファイルを使用します。

CSS とコンポーネントのスタイル設定

Lightning Web コンポーネントの CSS の実装は、W3C 標準に準拠しています。スタイルシートを CSS ファイル内に作成でき、それが自動的に対応する HTML ファイルに適用されます。

Lightning Web コンポーネントは、コンポーネントをカプセル化して、それらをグローバル DOM から分離します。これを Shadow DOM というメカニズムで実行します。Shadow DOM は、DOM の「サブツリー」にコンポーネントの要素を保持できるようにする一般的な実装です (詳細は「リソース」セクションの Shadow DOM に関するリンク先を参照してください)。コンポーネントは、その外観と動作を他のアプリケーション内か、別のコンポーネントの子として保持できます。

例として、自転車の価格を緑色の太字で表示するように設定してみましょう。次の .price エントリを detail.css ファイルに追加します。

body{
  margin: 0;
}
.price{
  color: green;
  font-weight: bold;
}

ファイルを保存してリリースします。

detail フォルダーを右クリックして新しいファイルのみをリリースすることができ、プロジェクト全体のリリースまで待たずにすみます。

ページがキャッシュされている場合、組織でその変更を表示するのに自転車セレクターアプリケーションページの更新が必要になることがあります。その後、自転車を選択すると、価格が緑色の太字になります。

価格のスタイルによってテキストが緑色の太字になります。

Lightning Design System のスタイルの適用

Salesforce Lightning Design System (SLDS) は、Lightning Experience と一貫性があるデザインを提供する CSS フレームワークです。Lightning Experience または Salesforce モバイルアプリケーション内にある Lightning Web コンポーネントは、import ステートメントや静的リソースなしで SLDS を使用できます。

たとえば、SLDS の見出しスタイルを使用して detail コンポーネントのテキストを Lightning の標準のテキストのような外観にすることができます。detail.html ファイルを更新して、slds-text-heading_small および slds-text-heading_medium フォント設定を次のように使用します。

<template>
  <template lwc:if={product}>
    <div class="container">
      <div class="slds-text-heading_small">{product.fields.Name.value}</div>
      <div class="price">{product.fields.MSRP__c.displayValue}</div>
      <div class="description">{product.fields.Description__c.value}</div>
      <img class="product-img" src={product.fields.Picture_URL__c.value} alt={product.fields.Name.value}/>
      <p>
        <lightning-badge label={product.fields.Material__c.value}></lightning-badge>
        <lightning-badge label={product.fields.Level__c.value}></lightning-badge>
      </p>
      <p>
        <lightning-badge label={product.fields.Category__c.value}></lightning-badge>
      </p>
    </div>
  </template>
  <template lwc:else>
    <div class="slds-text-heading_medium">Select a bike</div>
  </template>
</template>

ファイルを保存してリリースします。

組織でコンポーネントを試し、違いを確認してください (ページの更新が必要になります)。

SLDS 見出しフォント処理が適用されました。

良いですね! これで、このデザインを使用できるようになりました。(このモジュールを完了した後に、マークアップの変更と SLDS スタイルをさらに練習して見てください。「モバイル対応マークアップ」のアイデアを参考にして、このアプリケーションを使っていろいろと試してください。)

これまでは data コンポーネントから取得した静的データを使用してきました。もう 1 つ画期的なものをページに追加しましょう。動的データです。

Salesforce データの取得

結局のところ、これは Salesforce アプリケーションであり、本当にやりたいことは Salesforce 組織から動的データを取得できるようにすることです。Lightning Web コンポーネントは、Lightning データサービス上に構築されているリアクティブな wire サービスを使用します。名前をアプリケーションに動的に取得する例を手順に従って確認しましょう。

wire サービスでデータをアプリケーションに取得

wire サービスはプラットフォームの一部で、データのストリームを配信します。@wire デコレーター (前に簡単に言及) が、アプリケーション用の wire サービスを実装します。wire サービスを使用するには、次の手順を実行します。

JavaScript ファイルで wire アダプターをインポートします。
@wire デコレーターでプロパティまたは関数をデコレートします。

構文は次のとおりです。

import { adapterId } from 'adapter-module';
@wire(adapterId, adapterConfig) propertyOrFunction;

adapterId (ID) — wire アダプターの ID。
adapter-module (文字列) — wire アダプター関数が含まれるモジュールの ID。
adapterConfig (オブジェクト) — wire アダプター固有の設定オブジェクト。
propertyOrFunction — wire サービスからデータのストリームを受信する非公開のプロパティまたは関数。プロパティが @wire でデコレートされている場合、結果はそのプロパティの data プロパティまたは error プロパティに返されます。関数が @wire でデコレートされている場合、結果は data プロパティと error プロパティを持つオブジェクトで返されます。

それをこれまで作業してきたプロジェクトの selector.js ファイルに次のように追加して、組織から現在のユーザーの名前を取得します。

import { LightningElement, wire } from 'lwc';
import { getRecord, getFieldValue } from 'lightning/uiRecordApi';
import Id from '@salesforce/user/Id';
import NAME_FIELD from '@salesforce/schema/User.Name';
const fields = [NAME_FIELD];
export default class Selector extends LightningElement {
  selectedProductId;
  handleProductSelected(evt) {
    this.selectedProductId = evt.detail;
  }
  userId = Id;
  @wire(getRecord, { recordId: '$userId', fields })
  user;
  get name() {
    return getFieldValue(this.user.data, NAME_FIELD);
  }
}

行 1 で、wire サービスを lwc からインポートします。
行 2 で、getRecord と getFieldValue の adapterId と adapter-module を lightning/uiRecordApi からインポートします。
行 3 で、@salesforce モジュールを使用して現在のユーザー ID をインポートします。
行 4 で、User.Name の @salesforce スキーマをインポートします。
行 12 で、@wire デコレーターを使用して、ワイヤーサービスで getRecord をコールし、userId を渡して fields を取得します。
行 13 で、user を @wire コールのレシーバーとして設定します。

selector.html ファイルを編集し、name を追加して試すこともできます。次に例を示します。

<template>
  <div class="wrapper">
    <header class="header">Available Bikes for {name}</header>
    <section class="content">
      <div class="columns">
        <main class="main" >
          <c-list onproductselected={handleProductSelected}></c-list>
        </main>
        <aside class="sidebar-second">
          <c-detail product-id={selectedProductId}></c-detail>
        </aside>
      </div>
    </section>
  </div>
</template>

selector コンポーネントファイルを組織に保存してリリースすると (リリースに selector ファイルが含まれていることを確認してください)、次のようになります (Mary Jones が自分の名前に変わります)。ページの更新が必要になることがあります。

UI に動的に読み込まれたユーザー名。

モバイル対応マークアップ

自転車セレクターアプリケーションを構成する Lightning コンポーネントのマークアップはクリーンで合理化されおり、Lightning Web コンポーネントの基本を集中して学ぶことができるように設計されていますが、モバイルに対応していません。Salesforce モバイルアプリケーションでどのように表示されるのかを見てみましょう。またはモバイルプレビューで確認してみます。正常には動作しますが、優れたモバイルエクスペリエンスではありません。

この例のモバイル表示は好ましいものではありません。

SLDS を使用する利点の 1 つは、ほんの少しの作業で、デスクトップとモバイルの両方で見栄え良く表示されるデザインが手に入るということです。さらに詳しく説明したいのは山々ですが、このモジュールではすでに多くの内容を取り上げています。モバイルユーザーにとって使いやすい Lightning コンポーネントを作成するツールや手法についての詳細は、この単元の最後にある「リソース」を参照してください。

ここではモバイルを後回しにしましたが、実際に Lightning コンポーネントの開発を開始するときには、その逆を強くお勧めします。開発を開始する時点で、モバイルの詳細とデザインを検討してください。SLDS と Salesforce のモバイルプレビューツールを使用すれば、モバイル用とデスクトップ用のデザインを最初から両方一緒に簡単に作成できます。

客観的に評価させてもらうと、このモジュールは早い段階でモバイルについて検討しない場合の危険性を示す例であると言えます。実は、自転車セレクターアプリケーションがモバイルデバイスで見づらいというフィードバックが寄せられたとき、ほんの少しの作業で済むと思い、すぐに変更を加えました。ただし、アプリケーションのマークアップがクリーンで、そのセマンティックが熟慮されたものであったとしても、モバイルに対応するために後からアプリケーションを改良するのは正しいことではないと判断しました。今後、マークアップだけではなく、その説明とハンズオン Challenge も改訂したいと考えています。実際には、このモジュールの構造と流れそのものを変更することになります。最初に行った作業も決して少なくないので、大変なことではありますが、

ときには仕方のないことです。すべてのテクノロジーシステムの実装には妥協が伴うものです。チームとプロジェクトにとって適切な妥協点を見いだす必要があります。プロジェクトでは、このような妥協を肝に銘じておいてください。事前に理解していれば適切に対応することができます。

まとめ

これは始まりにすぎません。Lightning Web コンポーネントモデルでは多くのことができます。このモデルには、テスト、セキュリティ、Apex インテグレーションなどのサポートが含まれています。常に探索し、新しいことを試し、開発を続けてください。W3C Web コンポーネント標準が進化すると、このモデルも進化します。

Lightning Web コンポーネントの未来へと続く道。

ヘルプをお探しですか?

もっと探す