この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。
英語に切り替える

コンポーネントの API バージョンを混在させない

一貫性を保ちデバッグを容易にするため、アプリケーション、コンテインメント階層 (コンポーネント内のコンポーネント)、または拡張階層 (コンポーネントを拡張するコンポーネント) のすべてのコンポーネントに同じ API バージョンを設定することをお勧めします。

コンテインメント階層または拡張階層に API バージョンが混在し、Lightning Locker が有効なコンポーネントと無効なコンポーネントがある場合、アプリケーションのデバッグが難しくなります。

拡張階層

Lightning Locker は、コンポーネントのバージョンのみに基づいてコンポーネントまたはアプリケーションで有効化されます。コンポーネントの拡張階層は、Lightning Locker の適用には考慮されません。

Car コンポーネントが Vehicle コンポーネントを拡張する例を見てみましょう。Car の API バージョンは 39.0 であるため、Lightning Locker は無効です。Vehicle の API バージョンは 40.0 であるため、Lightning Locker は有効です。

ここで、window._counter に値を割り当てることで、Vehicle の expando プロパティ _counterwindow オブジェクトに追加するとします。Vehicle では Lightning Locker が有効なため、_counter プロパティは、コンポーネントの名前空間での window のセキュアなラッパーである SecureWindow に追加されます。このプロパティはネイティブの window オブジェクトには追加されません。

Car では Lightning Locker が無効なため、コンポーネントはネイティブの window オブジェクトにアクセスできます。_counter プロパティは SecureWindow でのみ使用できるため、Car はこのプロパティを参照できません。

この微妙な動作によって、コードが期待どおりに機能しない場合の対処に苦労する可能性があります。そのデバッグに費やした時間は戻ってきません。拡張階層のすべてのコンポーネントで同じ API バージョンを使用すれば、このような問題を回避できます。

コンテインメント階層

アプリケーションまたはコンポーネント内のコンテインメント階層は、Lightning Locker の適用には考慮されません。

Bicycle コンポーネントに Wheel コンポーネントが含まれる例を見てみましょう。Bicycle の API バージョンが 40.0 の場合、Lightning Locker は有効です。Wheel の API バージョン が 39.0 の場合、Lightning Locker が有効な Bicycle コンポーネントに含まれているにも関わらず、Wheel では Lightning Locker が無効になります。

コンポーネントの API バージョンの混在によって、拡張階層と同様の問題が発生する可能性が高くなります。可能な場合は、アプリケーションまたはコンポーネント階層のすべてのコンポーネントに同じ API バージョンを設定することをお勧めします。