Gutenberg: Compare los diferentes enfoques técnicos
Hasta ahora, tenemos estos prototipos técnicos:
1- https://wordpress.github.io/gutenberg/tinymce-per-block/
- Multi-TinyMCE
- Controlado (estado -> renderizar -> evento -> estado -> volver a renderizar)
- El estado se representa como un objeto
- Usando gramática
2- https://wordpress.github.io/gutenberg/tinymce-single/ (Single TinyMCE, no controlado, sin gramática, análisis HTML)
- TinyMCE global único
- Sin control (estado -> render -> evento -> newState)
- El estado es una cadena simple que contiene todo el HTML.
- No usamos la gramática dentro del editor, pero es posible que podamos agregar los comentarios gramaticales mientras llamamos
tinymce.getContent
(No dude en agregar cualquier otro prototipo técnico aquí)
Estoy creando este problema para que podamos comparar los pros y los contras de cada enfoque para ayudarnos a decidir qué enfoque elegimos implementar.
youknowriad
Todos 3 comentarios
Aquí están mis sentimientos sobre estos dos prototipos:
Prototipo 1:
Pros:
- Parece más fácil de usar Bloques fuera del contexto del editor
- Tengo una preferencia personal sobre tener el estado como un Objeto, la manipulación externa del estado (acciones no integradas en TinyMCE) parece más fácil de lograr.
Contras:
- La selección de bloques múltiples parece imposible de lograr. Ctrl + A es por bloque.
Prototipo 2:
Pros:
- Selección de bloques múltiples
- Más fácil de lograr una sensación de interfaz de usuario de texto completo
Contras
- ¿Es más difícil reutilizar los bloques fuera del editor?
- TinyMCE puede anular algunos de los comportamientos predeterminados dentro del contenido del bloque https://wordpress.slack.com/archives/core-tinymce/p1487169326000067
Basado en este prototipo experimental https://github.com/WordPress/gutenberg/pull/113 intenté trabajar en un enfoque mixto en el que usamos TinyMCE como envoltorio, pero volvemos a reproducir su contenido en función de los cambios de estado. Después de un poco de exploración, este enfoque parece intentar recrear DraftJS o ProseMirror. Y no creo que sea la forma correcta de usar TinyMCE.
youknowriad
en 23 feb. 2017
Gracias por crear este ticket.
Al comparar, también deberíamos pensar en el n. ° 3, ya que parece depender del enfoque que elijamos.
jasmussen
en 23 feb. 2017
Creo que Prototype 2 es el camino a seguir, aunque podría ser más complicado porque implicará mucho más trabajo de TinyMCE, en última instancia, probablemente sería el mejor enfoque a seguir por ahora.
¿Es más difícil reutilizar los bloques fuera del editor?
Creo que eso no sería una estafa para Prototype 2, siempre que la API para definir los tipos de bloques y los tipos de control proporcione datos suficientes para que los use algo diferente a TinyMCE. Creo que deberíamos desarrollar una API que defina el tipo de bloque / tipo de control que se utilizará para alimentar una instancia de TinyMCE altamente personalizada. Los datos del tipo de bloque / tipo de control también podrían usarse para alimentar algo más potencialmente en el futuro.
Por mucho que probablemente no sea aceptable, Prototype 2 refleja al máximo cómo WordPress ya funciona y TinyMCE hace mucho, lo que para mí lo convierte en un camino muy sensato a seguir.
BE-Webdesign
en 21 mar. 2017
Temas relacionados
BE-Webdesign
·
3Comentarios
spocke
·
3Comentarios
mhenrylucero
·
3Comentarios
cr101
·
3Comentarios
aaronjorbin
·
3Comentarios
Comentario más útil
Aquí están mis sentimientos sobre estos dos prototipos:
Prototipo 1:
Pros:
Contras:
Prototipo 2:
Pros:
Contras
Basado en este prototipo experimental https://github.com/WordPress/gutenberg/pull/113 intenté trabajar en un enfoque mixto en el que usamos TinyMCE como envoltorio, pero volvemos a reproducir su contenido en función de los cambios de estado. Después de un poco de exploración, este enfoque parece intentar recrear DraftJS o ProseMirror. Y no creo que sea la forma correcta de usar TinyMCE.