Gutenberg: Comparer les différentes approches techniques

Créé le 23 févr. 2017 · 3Commentaires · Source: WordPress/gutenberg

Jusqu'à présent, nous avons ces prototypes techniques :

1- https://wordpress.github.io/gutenberg/tinymce-per-block/

Multi-TinyMCE
Contrôlé ( état -> rendu -> événement -> état -> rendu )
L'état est représenté comme un objet
Utiliser la grammaire

2- https://wordpress.github.io/gutenberg/tinymce-single/ (Single TinyMCE, non contrôlé, pas de grammaire, analyse HTML)

TinyMCE mondial unique
Non contrôlé ( état -> rendu -> événement -> nouvel état )
L'état est une simple chaîne contenant tout le code HTML
Ne pas utiliser la grammaire dans l'éditeur mais nous pouvons peut-être ajouter les commentaires de grammaire en appelant tinymce.getContent

(N'hésitez pas à ajouter tout autre prototype technique ici)

Je crée ce problème afin que nous puissions comparer les avantages / inconvénients de chaque approche pour nous aider à décider quelle approche nous choisissons de mettre en œuvre.

[Type] Question

Source

youknowriad

Commentaire le plus utile

Voici mon ressenti sur ces deux prototypes :

Prototype 1 :

Avantages:

Semble plus facile à utiliser Blocks en dehors du contexte de l'éditeur
J'ai une préférence personnelle pour avoir l'état en tant qu'objet, la manipulation externe de l'état (actions non intégrées dans TinyMCE) semble plus facile à réaliser.

Les inconvénients:

La sélection multi-blocs semble impossible à réaliser. Ctrl+A est par bloc.

Prototype 2:

Avantages:

Sélection multi-blocs
Plus facile d'obtenir un sentiment d'interface utilisateur en texte intégral

Les inconvénients

Plus difficile de réutiliser les blocs en dehors de l'éditeur ?
TinyMCE peut remplacer certains des comportements par défaut dans le contenu du bloc https://wordpress.slack.com/archives/core-tinymce/p1487169326000067

Sur la base de ce prototype expérimental https://github.com/WordPress/gutenberg/pull/113, j'ai essayé de travailler sur une approche mixte où nous utilisons TinyMCE comme wrapper mais restituons son contenu en fonction des changements d'état. Après quelques explorations, cette approche donne l'impression d'essayer de recréer DraftJS ou ProseMirror. Et je ne pense pas que ce soit la bonne façon d'utiliser TinyMCE.

youknowriad le 23 févr. 2017

❤3

Tous les 3 commentaires

Voici mon ressenti sur ces deux prototypes :

Prototype 1 :

Avantages:

Semble plus facile à utiliser Blocks en dehors du contexte de l'éditeur
J'ai une préférence personnelle pour avoir l'état en tant qu'objet, la manipulation externe de l'état (actions non intégrées dans TinyMCE) semble plus facile à réaliser.

Les inconvénients:

La sélection multi-blocs semble impossible à réaliser. Ctrl+A est par bloc.

Prototype 2:

Avantages:

Sélection multi-blocs
Plus facile d'obtenir un sentiment d'interface utilisateur en texte intégral

Les inconvénients

Plus difficile de réutiliser les blocs en dehors de l'éditeur ?
TinyMCE peut remplacer certains des comportements par défaut dans le contenu du bloc https://wordpress.slack.com/archives/core-tinymce/p1487169326000067

youknowriad le 23 févr. 2017

❤3

Merci d'avoir créé ce billet.

Lorsque nous comparons, nous devrions également penser au numéro 3, car cela semble dépendre de l'approche que nous choisissons.

jasmussen le 23 févr. 2017

Je pense que le Prototype 2 est la voie à suivre, bien que cela puisse être plus pénible car cela impliquera beaucoup plus de travail TinyMCE, en fin de compte, ce serait probablement la meilleure approche pour le moment.

Plus difficile de réutiliser les blocs en dehors de l'éditeur ?

Je pense que ce ne serait pas un inconvénient pour Prototype 2, tant que l'API pour définir les types de blocs et les types de contrôle fournit suffisamment de données pour autre chose que TinyMCE à utiliser. Je pense que nous devrions développer une API de définition de type de bloc/type de contrôle qui sera utilisée pour alimenter une instance TinyMCE hautement personnalisée. Les données du type de bloc/type de contrôle pourraient également être utilisées pour alimenter quelque chose d'autre potentiellement à l'avenir.

Même s'il n'est probablement pas acceptable, Prototype 2 reflète au mieux la façon dont WordPress fonctionne déjà et TinyMCE en fait beaucoup, ce qui en fait pour moi une voie à suivre très sensée.