CMSでのエディターエクスペリエンスと開発者エクスペリエンスの調整

再利用可能なコンポーネントは、堅牢でコード効率の良いフロントエンドを構築するのに最適です。同様に強力なのは、コンテンツの編集をフロントエンドプレゼンテーションと区別するヘッドレスコンテンツ管理です。これにより、APIが消費するフロントエンドへの柔軟なコンテンツの構造化と配信が可能になります。この組み合わせは、Jamstackアーキテクチャの基礎です。

ただし、コンポーネントベースのフロントエンドをヘッドレスCMSエクスペリエンスに合わせるのは難しい場合があります。それらを接続することは本質的に難しくありませんが、CMSエディターのエクスペリエンスを反映する再利用可能で一貫したコンポーネントシステムを作成するには、慎重に検討する必要があります。理想的なシナリオは、シームレスなコンテンツ作成と予測可能なコンポーネント構造です。

CMSとフロントエンドコンポーネントの間のギャップを橋渡しします

シンプルなボタンコンポーネントは、この複雑さを示しています。 Reactでは、ボタンが（宛先をリンクする）およびchildren （ボタンテキスト）プロパティを（ボタンテキスト） to必要がある場合があります。コンテンツエディターの場合、これらのプロパティ名は直感的ではありません。

これに対処するために、いくつかのアプローチを探ります。

CMSフィールドをコンポーネントプロパティに一致させます

CMSフィールド（ to ）をコンポーネントプロパティに直接マッピングするとchildrenしばしば失敗します。編集者は、これらの用語が混乱していると感じています。 CMSで「ラベル」や「URL」などのよりユーザーフレンドリーなラベルを使用すると、使いやすさが向上しますが、コードに不一致を作成します。

マスキング属性

ヘッドレスCMSは、多くの場合、API名とは異なるラベルフィールドを許可します。 CMSで「ラベル」と「URL」を使用できますが、コードでは「子供」と「」を使用できます。ただし、これにより、デバッグの複雑さが追加され、CMSラベルとコードプロパティの関係が不明瞭になります。

コンポーネントプロパティの変更

CMSのフィールド名を一致させるためにコンポーネントプロパティを適応させると、柔軟性を制限し、矛盾につながる可能性があります。 CMSデータにlabelとurl動作を使用しますが、機能（アイコンなど）を追加するには、追加のロジックまたはプロパティが必要であり、コンポーネントの設計を損なう可能性があります。

トランスソリューション

最適なソリューションには、編集者と開発者のエクスペリエンスを分離することが含まれます。エディタの使いやすさのためのCMSと開発者の効率のためのコードベースを設計します。直接パリティはありそうもないので、トランスを導入します。

トランスは、Frameworkに関係なく、フロントエンドコンポーネントによって簡単に消費されるフォーマットにCMSデータを変換するユーティリティです。 3つの実装アプローチが存在します。

1。コンポーネントレベルの変圧器

対応するコンポーネントに沿ってトランスを配置します。これにより、関連するファイルが一緒になります。 index.jsファイルはコントローラーとして機能し、コンポーネントとその変圧器をインポートおよびエクスポートします。変圧器は、レンダリング前にプロパティを変更します。

私たちのボタンのために：

 // index.js
「React」からのImport React;
"./Component"からコンポーネントをインポートします。
「./Transformer」からのインポート変換。

const button =（props）=><component></component> ;

デフォルトボタンのエクスポート。

 // Transformer.js
デフォルトをエクスポート（入力）=>（{
  ...入力、
  子供：input.children || input.label、
  to：input.to || input.url、
}）;

 // component.js
const button =（{children、to}）=> <a href="%7Bto%7D">{children}</a> ;

このアプローチはシンプルで、ロジックをローカライズしていますが、多くのファイルにつながる可能性があります。

2。ファンネルの最上部変換

最初にアプリケーションにフェッチされているポイントでデータを変換します。これにより、ブラウザのワークロードが削減され、パフォーマンスが向上します。ただし、特に大きく複雑なデータ構造では、複雑さが大幅に向上します。テストはより困難になります。

3。専用変換エンジン

すべての変換を処理するための個別のアプリケーションを作成します。これは最も複雑ですが、複数のプロジェクトで再利用性を提供します。オーバーヘッドを追加しますが、集中型の保守可能なソリューションを提供します。

コンポーネントレベルの変圧器から始めて、必要に応じてより複雑なアプローチに進みます。重要なのは、編集者と開発者の両方にとって楽しく効率的なエクスペリエンスを作成することです。

以上がCMSでのエディターエクスペリエンスと開発者エクスペリエンスの調整の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。