Salesforceの「反応型画面フロー」を活用する際の注意点を以下にまとめました。効率的な実装の参考にしてください。
反応型画面フローとは
反応型画面フローは、ユーザー入力や他の要素の変更に応じて画面項目を動的に更新する機能です。詳細については、公式ドキュメントを参照してください：
Salesforce ドキュメント: 反応型画面フローの概要
注意点 1: 複雑な画面には不向き
反応型画面フローは、連動関係が複雑な画面には適していません。
-
理由: 画面項目同士の連携が複雑な場合、連鎖的な更新（連鎖反応）が発生し、画面のローディング時間が大幅に延びる可能性があります。
現状（2024/12/19）では、パフォーマンスに課題があり、将来的な改善が期待されます。 -
解決策: パフォーマンス問題が発生した場合、画面全体を LWC（Lightning Web Components） で実装することで改善できます。
注意点 2: FlowAttributeChangeEventは2箇所で発火する
画面フロー向けのLWCを開発する際は、FlowAttributeChangeEventを以下の2箇所で発火させることを推奨します。
- プロパティの
setter connectedCallback()
理由
-
connectedCallback()で再発火する必要性:
LWC初期化時、setterでFlowAttributeChangeEventが発火しますが、この時点ではLWCがDOMに挿入されていないため、他のLWCにイベントが届きません。
そのため、DOMに挿入された後、connectedCallback()で再度発火する必要があります。 -
DOM挿入後の発火:
connectedCallback()内で発火すれば、画面フロー内の他のLWCに必ずイベントが届きます。
例えば、画面に２つのLWCがあります。LWC1がconnectedCallback()でFlowAttributeChangeEventを発火する際、LWC2がまだ初期化されていなくても、後にDOMへ挿入された際にイベントを受け取ることが可能です。
補足
LWCのライフサイクルとDOM挿入のタイミングについて詳しく理解することが重要です。
以下の図を参照してください：
参考資料:
Lightning Web Components: リアクティビティのベストプラクティス
注意点 3: Promise.resolve().then(...)の使用を控える
FlowAttributeChangeEventを発火する際に、Promise.resolve().then(...)の使用を避けるべき理由は以下の通りです。
- 理由1: 実行順序が変更されるため、デバッグが難しくなります。
- 理由2: 実行順序の予測が困難になり、予測外の動作はバグの原因になる。
また、setTimeoutを使用して発火させる方法も同様に避けることを推奨します。
以上が反応型画面フローを実装する際の注意点です。効率的かつトラブルの少ない開発にお役立てください。