Gutenberg: Compare as diferentes abordagens técnicas

Criado em 23 fev. 2017 · 3Comentários · Fonte: WordPress/gutenberg

Até agora, temos estes protótipos técnicos:

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

Multi-TinyMCE
Controlado (estado -> renderizar -> evento -> estado -> renderizar novamente)
O estado é representado como um objeto
Usando gramática

2- https://wordpress.github.io/gutenberg/tinymce-single/ (TinyMCE único, não controlado, sem gramática, análise de HTML)

TinyMCE global único
Não controlado (estado -> render -> evento -> novo estado)
O estado é uma string simples contendo todo o HTML
Não usando a gramática dentro do editor, mas podemos adicionar comentários de gramática enquanto chamamos tinymce.getContent

(Sinta-se à vontade para adicionar qualquer outro protótipo técnico aqui)

Estou criando este problema para que possamos comparar os prós / contras de cada abordagem para nos ajudar a decidir qual abordagem escolhemos implementar.

[Type] Question

Fonte

youknowriad

Comentários muito úteis

Aqui estão meus sentimentos sobre esses dois protótipos:

Protótipo 1:

Prós:

Parece mais fácil usar blocos fora do contexto do editor
Tenho uma preferência pessoal sobre ter o estado como um objeto, a manipulação externa do estado (ações não integradas no TinyMCE) parece mais fácil de alcançar.

Contras:

A seleção de vários blocos parece impossível de ser alcançada. Ctrl + A é por bloco.

Protótipo 2:

Prós:

Seleção multi-bloco
Mais fácil de alcançar uma sensação de IU de texto completo

Contras

Mais difícil reutilizar os blocos fora do editor?
TinyMCE pode substituir alguns dos comportamentos padrão dentro do conteúdo do bloco https://wordpress.slack.com/archives/core-tinymce/p1487169326000067

Com base neste protótipo experimental https://github.com/WordPress/gutenberg/pull/113 tentei trabalhar em uma abordagem mista, onde usamos o TinyMCE como um wrapper, mas renderizamos seu conteúdo com base nas mudanças de estado. Depois de alguma exploração, essa abordagem parece tentar recriar DraftJS ou ProseMirror. E não acho que seja a maneira certa de usar o TinyMCE.

youknowriad em 23 fev. 2017

❤3

Todos 3 comentários

Aqui estão meus sentimentos sobre esses dois protótipos:

Protótipo 1:

Prós:

Parece mais fácil usar blocos fora do contexto do editor
Tenho uma preferência pessoal sobre ter o estado como um objeto, a manipulação externa do estado (ações não integradas no TinyMCE) parece mais fácil de alcançar.

Contras:

A seleção de vários blocos parece impossível de ser alcançada. Ctrl + A é por bloco.

Protótipo 2:

Prós:

Seleção multi-bloco
Mais fácil de alcançar uma sensação de IU de texto completo

Contras

Mais difícil reutilizar os blocos fora do editor?
TinyMCE pode substituir alguns dos comportamentos padrão dentro do conteúdo do bloco https://wordpress.slack.com/archives/core-tinymce/p1487169326000067

youknowriad em 23 fev. 2017

❤3

Obrigado por criar este tíquete.

Ao comparar, devemos também pensar no nº 3, já que parece dependente da abordagem que escolhermos.

jasmussen em 23 fev. 2017

Eu acho que o Protótipo 2 é o caminho a percorrer, embora possa ser mais doloroso porque envolverá muito mais trabalho do TinyMCE; em última análise, provavelmente seria a melhor abordagem por enquanto.

Mais difícil reutilizar os blocos fora do editor?

Acho que isso não seria um contra para o Prototype 2, contanto que a API para definir os tipos de bloco e os tipos de controle forneça dados suficientes para algo diferente do TinyMCE usar. Acho que devemos desenvolver um tipo de bloco / tipo de controle definindo API que será usado para alimentar uma instância TinyMCE altamente personalizada. Os dados do tipo de bloco / tipo de controle também podem ser usados para alimentar algo potencialmente no futuro.

Por mais que provavelmente não seja palatável, o Prototype 2 espelha ao máximo como o WordPress já funciona e o TinyMCE faz muito, o que para mim o torna um caminho muito sensato a seguir.