Réconcilier l'expérience de l'éditeur et l'expérience des développeurs dans la CMS

Les composants réutilisables sont fantastiques pour construire des fins frontales robustes et économes en code. Tout aussi puissant est la gestion de contenu sans tête, qui sépare l'édition de contenu de la présentation frontale. Cela permet une structuration et une livraison de contenu flexible à n'importe quel frontal consommant de l'API. Cette combinaison est une pierre angulaire de l'architecture Jamstack.

Cependant, l'alignement du frontal basé sur les composants avec l'expérience CMS sans tête peut être difficile. Bien que les connecter n'est pas intrinsèquement difficile, la création d'un système de composants réutilisable et cohérent qui reflète l'expérience de l'éditeur CMS nécessite une attention particulière. Le scénario idéal est la création de contenu transparente et la structuration des composants prévisibles.

Combler l'écart entre CMS et les composants frontaux

Un composant de bouton simple illustre cette complexité. Dans React, un bouton peut avoir to (Link Destination) et children (Texte du bouton). Pour les éditeurs de contenu, ces noms de propriétés sont moins intuitifs.

Pour y remédier, nous explorons plusieurs approches:

Correspondance des champs CMS aux propriétés des composants

La cartographie directe des champs CMS ( to et children ) aux propriétés des composants échoue souvent. Les éditeurs trouvent ces termes déroutants. L'utilisation d'étiquettes plus conviviales comme "Label" et "URL" dans le CMS améliore la convivialité mais crée un décalage avec le code.

Attributs de masquage

Les CMS sans tête permettent souvent des champs d'étiquetage différemment de leurs noms API. Nous pourrions utiliser "étiquette" et "URL" dans le CMS, mais "enfants" et "à" dans le code. Cependant, cela ajoute de la complexité de débogage, masquant la relation entre les étiquettes CMS et les propriétés de code.

Modification des propriétés des composants

L'adaptation des propriétés des composants pour correspondre aux noms de champ CMS semble simple, mais il peut limiter la flexibilité et entraîner des incohérences. L'utilisation label et url fonctionne pour les données CMS, mais l'ajout de fonctionnalités (comme les icônes) nécessite une logique ou des propriétés supplémentaires, sapant potentiellement la conception du composant.

La solution de transformateur

La solution optimale consiste à séparer les expériences des éditeurs et des développeurs. Concevez le CMS pour la facilité d'utilisation de l'éditeur et la base de code pour l'efficacité du développeur. Étant donné que la parité directe est peu probable, nous présentons des transformateurs .

Les transformateurs sont des utilitaires qui convertissent les données CMS en un format facilement consommé par les composants frontaux, quel que soit le cadre. Il existe trois approches de mise en œuvre:

1. Transformers au niveau des composants

Placez les transformateurs à côté de leurs composants correspondants. Cela maintient les fichiers connexes ensemble. Un fichier index.js agit comme un contrôleur, importation et exportation du composant et de son transformateur. Le transformateur modifie les propriétés avant le rendu.

Pour notre bouton:

 // index.js
importer réagir à partir de "réagir";
Importer le composant à partir de "./component";
Transforment d'importation à partir de "./transformateur";

const Button = (accessoires) =><component></component> ;

Exporter le bouton par défaut;

 // transformateur.js
Export Default (Input) => ({
  ...saisir,
  Enfants: entrée.children || input.label,
  à: entrée.to || entrée.url,
});

 // composant.js
const Button = ({enfants, à}) => <a href="%7Bto%7D">{enfants}</a> ;

Cette approche est simple et maintient la logique localisée, mais elle peut conduire à de nombreux fichiers.

2. Transformation haut de gamme

Transformez les données au point où elle est initialement récupérée en application. Cela réduit la charge de travail du navigateur, améliorant les performances. Cependant, il augmente considérablement la complexité, en particulier avec de grandes structures de données complexes. Les tests deviennent plus difficiles.

3. Moteur de transformation dédié

Créez une application distincte pour gérer toutes les transformations. Il s'agit du plus complexe, mais offre une réutilisabilité sur plusieurs projets. Il ajoute des frais généraux mais fournit une solution centralisée et maintenable.

Commencez par les transformateurs au niveau des composants et progressez vers des approches plus complexes au besoin. La clé est de créer une expérience agréable et efficace pour les éditeurs et les développeurs.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!