次のステップの確認

学習の目的

この単元を完了すると、次のことができるようになります。
  • より詳しく探ることができる Aura コンポーネントの 5 つの側面を挙げる。
  • Expenses アプリケーションに加えることができる 3 つの改善を計画する。
  • このバッジを獲得する。

これで完了です。

作業はこれで完了です。よくここまでついてきてくれました。このモジュールは非常に厳しいため、このバッジを獲得することは大きな意味があります。これで完了です。

この単元の課題をクリアすれば、バッジを獲得できます。これまではかなりの努力が必要だったため、この単元は簡単にしています。ただし、読み飛ばさないでください。この単元は課題という意味では「簡単」ですが、Lightning コンポーネント開発者として成功するには、この単元はあらゆる点で他のすべての単元と同じくらい重要です。

「Aura コンポーネントの基本」モジュールでは Aura コンポーネントを使用したアプリケーション開発の基本について説明しましたが、これはほんの始まりにすぎません。このモジュールはここまで十分に長い時間がかかっていますが、実際にはこの他にさらに多くの学ぶべきことがあります。少なくとも、Lightning コンポーネントの達人になるにはその学習が必要です。

この単元では、2 つのトピックを取り上げます。まずは、このモジュールで取り扱う余裕がなかった内容の概要と、その内容について学習できる場所を示します。その後に、いくつかの課題形式のプロジェクトを提案します。各自で試してみることができる、今回の小規模な Expenses アプリケーションへの「明白な」追加機能が多数あります。最適な学習方法は、実際にやってみることです。

これまで言及のみで終了したトピック

Expenses アプリケーションを作成したときに、「ここではこれについては説明しません」と数えきれないほど言ってきました。できれば説明したかったことで、みなさんもそれを望んでいたかもしれませんが、このモジュールでさらに 8 時間かけてすべて説明していたらうんざりするでしょう。

Salesforce Lightning Design System

SLDS は、アプリケーションに Lightning Experience のスタイルを実装するための堅牢、柔軟かつ包括的なシステムです。Lightning コンポーネント、Visualforce、および単純なマークアップでさえも SLDS を使用できます。Salesforce ドキュメントチームのライターはこれを使用してあるプロトタイプを作成しましたが、それについてはまだお話できません。

SLDS は楽しく学べ、使用するとさらに楽しめます。それ専用の (Visualforce を使用した) Trailhead モジュールや、その使用方法を示した多数の Trailhead プロジェクトがあります。他にも、この普及を目的とした驚くほど便利な Web サイトもあります。

Lightning コンポーネントを使用できる場所

このトピックは一連のスクリーンショットで済ませて詳しく説明しませんでしたが、Lightning コンポーネントは Salesforce の内外問わず、多数の方法で使用できます。

具体的には、スタンドアロンの「my.app」の作成のみを説明してきました。Salesforce アプリケーションと Lightning Experience にアプリケーションを追加する方法も学ぶ必要があります。幸いにも、この方法は非常に簡単です。なぜここで説明しなかったのか疑問に思うかもしれません (このまま読み進めてください)。

『Lightning コンポーネント開発者ガイド』は、Lightning コンポーネントアプリケーションの使用場所と使用方法に関する情報を得るための最適な場所です。

デバッグ

ここでは最も基本的なデバッグ方法のみを説明しました。いくつかの異なる洗練されたツールを使用して Lightning コンポーネントアプリケーションをデバッグする方法を学習すると、悩みの種が解消されて時間を節約できるという利点を得ることができます。

特に、Chrome の豊富なデベロッパーツールスイート、およびその内部で動作する Salesforce Lightning Inspector の学習をお勧めします。Apex 開発者は、Apex で使用可能なデバッグツールについても学習することをお勧めします。この多くは開発者コンソールで直接使用できます。

データ型

属性に使用できる「フレームワーク固有」のデータ型がいくつかあることを簡単に説明しました。これらは主にファセット、特に body ファセットで使用されます。ファセット、特に body は複雑で、基本的な Lightning コンポーネント開発には必須ではないため、このモジュールでは意図的に省略しました。ただし、コンポーネントの body (または他のファセット) を設定できるとコードや不自然さが大幅に削減されるため、いずれこの概念すべてについて学習することをお勧めします。

ヘルパー

このモジュールではかなり多くのヘルパーコードを記述しましたが、知っておく価値のあるいくつかの高度なヘルパーの使用方法があります。ヘルパーは再利用可能なコードを共有するための主な方法であるため、探索することが重要な領域です。

サーバ要求のライフサイクルと処理

$A.enqueueAction() を使用してサーバ要求を行う方法、および成功時の応答を処理する方法について説明しました。その他の状況が発生する可能性もあるため、その処理を行う方法も知っておく必要があります。また、要求には多くの異なる種別もあり、正しい種別を使用することでアプリケーションのパフォーマンスを大幅に改善できる場合があります。

セキュリティ、セキュリティ、セキュリティ、セキュリティ

すでに何度も話しているため、ここでは説明しません。ただし、知っておきべきことはたくさんあります。

アプリケーションイベント

これについては言及のみしましたが、より大規模なアプリケーションでは重要になります。イベントの基本については説明しましたが、学ぶべきことはもっとたくさんあります。イベントのすべてを学習しない限り、Lightning コンポーネントで洗練されたアプリケーションを作成することはできません。

まったく取り扱わなかったトピック

単に言及すらしなかった多数のトピックもあります。それらのトピックは複雑か高度であるか、複雑かつ高度になっています。参考としてそのいくつかを次に示します。

他のバンドルリソース種別

4 つの Lightning コアコンポーネントバンドルリソース種別については説明しました。他にも 4 つあります。デザインリソースと SVG リソースはやや特殊な目的がありますが、ドキュメントリソースとレンダラリソースは Lightning コンポーネントで役立つ可能性があります。

ナビゲーション

これが基本であると考えていても仕方ありません。複雑な実際のアプリケーションでは、これが基本になるからです。多くの場合、Lightning Experience または Salesforce アプリケーションの内部で実行するナビゲーションの開発は実際には非常に簡単ですが、次の項目を参照してください。

コンポーネントの動的な作成

Lightning コンポーネントアプリケーション内を「移動」する主要な方法の 1 つは、ユーザのアクションに応じて新しいコンポーネントを動的に作成することです。この全領域は豊富かつ強力であまりにも複雑であるため、このモジュールに取り組むと一週間はかかってしまいます。$A.createComponent() を検索することで、探索を開始できます。

エラー処理

サーバのエラー処理と完全にクライアント側のエラー処理があります。このモジュールでは、常に処理は成功すると仮定しています。残念ながら、実際には信頼性を揺るがすバグと異常動作の両方が発生します。偉大なエンジニアは、「失敗する可能性のあるものは失敗する」という名言を残しています。そのため、可能な限りエラーを処理して回復する計画を立てることをお勧めします。

force: 名前空間のコンポーネントとイベント

Lightning コンポーネントアプリケーションが Lightning Experience と Salesforce アプリケーション内部で実行される場合、使用可能な多数の非常に便利なコンポーネントとイベントがあります。これらのコンポーネントの一部は別のコンテキストで動作しますが、その多くは Lightning Experience と Salesforce アプリケーションのみで使いやすくなっているため、ここでは説明しませんでした。

システムイベント

厳密に言えば、これについては init ハンドラの形式で触れましたが、init イベントがコンポーネントまたはアプリケーションライフサイクル中にキャッチできるシステムイベントの 1 つであることは説明しませんでした。(さらに言えば、そのライフサイクルについても説明しませんでした)。システムイベントは多数あり、それが存在する場合は特定の時点でコンポーネントに「何かを実行」させたり、特定の状況を処理したりするために使用できます。

冒険心のある開発者向けの課題

Lightning コンポーネントについてもっと学習したいという意欲を掻き立てられたでしょうか? 興味深い探索に役立ち、ここで学習したことに適合する、Expenses アプリケーションでできることのアイデアをいくつか次に示します。

登録後にフォームをクリアする

現時点では、[Create Expense (経費を作成)] ボタンをクリックしてもフォームは入力されたままになります。項目を空の文字列に設定することは簡単ですが、いつ行えばよいでしょうか? 必要な動作、使いやすさ、考えられるさまざまなサーバの応答 (成功以外) について考慮してください。

動作が決定したら、どこにコードを挿入すればよいでしょうか? 最初は簡単に思うかもしれませんが、サーバの応答処理は expenses 内にあり、フォーム項目は expenseForm 内にあることにすぐ気付くはずです。それではどのように処理すればよいでしょうか?

「Expense Saved (経費が保存されました)」というメッセージを表示する

経費がサーバに正常に保存されたときに、ユーザに成功メッセージを表示すると親切です。そのメッセージは、[Reimbursed? (払い戻し済み?)] チェックボックスの更新と新しい経費の作成で別にした方がいいかもしれません。または、メッセージをまったく表示したくない場合もあるかもしれません。

処理の失敗

項目のデータ入力規則が原因でレコードをサーバに保存できない場合はどうなるでしょうか? または、他のエラーが発生した場合は? 現時点では何も起こらず、アプリケーションが警告なしに失敗します。[Reimbursed? (払い戻し済み?)] チェックボックスでは、アプリケーションが誤った経費の状態を表示する可能性があります。このどちらも好ましくありません。

単純な失敗の処理に必要なコードの行数は実際にはそれほど多くありませんが、開始する前に調査する必要があります。

経費レコードの編集を許可する

これはやや高度ですが、フェーズごとに対処できます。まず、経費リストで経費をクリックしたときに、該当する経費の値がフォームに入力されるようにします。次に、[Create Expense (経費を作成)] ボタンのテキストを「Save Expense」 (経費を保存) に変更します。(常に「Save Expense」が表示されるようにはしないでください)。次に、フォームで起動されるイベントを新しい経費の作成から既存の経費の更新に変更します。

今日のところはここまでにします。Lightning コンポーネントアプリケーションの開発で名声、富、刺激を得られることを願っています。