Strapi CMS を介してマルチコンテンツ関係の作成にアクセスします

プラグイン開発

開発の最初の段階は概念実証で、CMS は GraphQL で開発されたバックエンドの背後にあり、さまざまなコンテンツの取得を可能にする Strapi クライアントをセットアップしました。 このアプローチは、UID と ID を使用して、さまざまな関連コンテンツを JSON 形式で保存し、BFF クライアントで使用することでした。

ここでは、大きな JSON ペイロードを受け入れるテーブルを利用して、保存が制限されないように、意図的に「richText」タイプを配置していることに注意してください。
続いて、この関係分野への貢献を可能にするバックオフィス部分の開発が続きました。 このために、私たちは次のものに依存しました。 デザインシステム Strapi が私たちに提供するもの。

カスタム フィールドの定義が確立されたら、設定に進みましょう。 フィールドが関係を持つすべてのコンテンツ タイプと、Strapi が提供していない基本機能 (必須フィールド (はい/いいえ)、最小値、最大値) を設定できるようにしたいと考えています。
バックオフィスを初期化するときに、プラグインは最初のルートを呼び出しますAPI カスタムの「listContentTypes」を使用すると、関係で使用できるすべてのコンテンツ タイプを取得できます。

基本的な構成を追加すると、リレーションシップ フィールドの利用の自由度が大幅に向上します。

カスタム フィールドの設定が完了したので、カスタム フィールドの表示と投稿に取り組んでみましょう。 バックオフィス部分の開発を数回繰り返した結果、Strapi のネイティブ入力マスクに簡単に統合できるものに到達しました。

上に示した図からいくつかのことがわかります。

• 設定されたさまざまなコンテンツ タイプ (この場合は「記事」と「イベント」) を検索できる入力フィールド。
• 最初のゾーンには、関係としてすでに選択されているコンテンツが表示されます。 最初の文字列フィールド、ID、コンテンツ タイプ、公開ステータスを確認できます。 プラグインは公開ステータスのないコンテンツを管理することに注意してください。 繰り返し可能な領域のコンポーネントと同様に、ドラッグ アンド ドロップで選択した要素の順序を簡単に変更できます。
  最後の領域は、関連して追加できる要素で構成されます。

そこで、さまざまなデータを取得できるカスタム エンドポイントを開発する必要がありました。

これら 2 つの API エンドポイントの詳細については、次を参照してください。

• 「getMatchingContent」エンドポイントは、Strapi の内部entityService を使用して、検索されたコンテンツ タイプの最初のテキスト フィールドの検索用語に一致するすべてのコンテンツを返します。
• 「ValidateRelation」エンドポイントを使用すると、非公開または削除された可能性のあるコンテンツを削除するために、このフィールドの 2 回目の表示中に選択したコンテンツを再検証できます。

カスタム プラグイン インターフェイスには、これらのさまざまなコンテンツとの関係を表す JSON が保存されます。

「MRCT」: true フィールドの存在により、strapi API 応答内のカスタム リレーションシップ フィールドの存在を識別できることに注意してください。このフィールドは、この記事の後半で使用されます。

プラグインの消費

可能な限りコンテンツを自動的にハイドレートするカスタム Strapi クライアントを実装しました。 これは、最終的なコンテンツを返す前に、コンテンツを識別してハイドレートするためにさまざまな段階を経ます。

• Strapi API 応答のすべてのプロパティを平坦化し、オブジェクトの再帰なしでフィールド トラバーサルの完全性を確保します。
• 各プロパティの内容に「MRCT」フラグの有無を確認: true、
• 特定されたプロパティに存在する JSON コンテンツの検証、
• コンテンツの回復、
• JSON フィールドをハイドレートされたコンテンツに置き換えます。
• プロパティを非平坦化して、元の構造と同じ構造に戻します。

完全な機能はここにあります。 https://gist.github.com/BaptisteKaliop/4c37048bc3225c8eb15598c6b3078e57

この関数ではいくつかの点を区別できます。

• コンテンツ取得における無限再帰を避けるための深さ管理の概念の追加 (コンテンツ A には B への MRCT が含まれており、コンテンツ自体には A への MRCT が含まれています)
• この機能が動作するには、追加の構成が必要です。たとえば、バックエンドでコンテンツ タイプを定義して、関連するコンテンツを正しくフェッチするための UID ⇔ Content-Type のマッピング (単一タイプ/コレクション タイプの管理など) が必要です。
• 同一のコンテンツを管理しないことで、何度か問題が発生しました。私たちの側では、現在のリクエストに固有のキャッシュを利用するために BFF データローダーに依存しています。

このような開発を経て、関係性から適切に水分補給されたコンテンツに到達します。

結論

このプラグインは 2 週間の 2 つのスプリントにわたって開発され、クライアントへの貢献に実際のダイナミクスをもたらすために、いくつかの可能な関係を持つコンポーネントを活用できるようになりました。

カスタム MRCT フィールドを含むコンテンツの周囲にライフサイクル フックを作成するという、大きな改善がまだ 1 つあることに留意してください。 このようにして、Strapi は、データが適切に提供されるように、データを提供する前に API 内のコンテンツをハイドレートするという全体的な負担を負います。

このプラグインは、CMS にとって不可欠と思われる機能上のニーズを満たすために、将来のバージョンでデフォルトで復活することを期待して、間もなく Strapi マーケットプレイスで公開される予定です。