Pessoalmente, dos que usei, este pareceu o mais confortável e o mais fácil de expandir.
Muitas das dificuldades que senti ao criar um editor com o Slate foram realmente resolvidas aqui.
Por acaso você poderia compartilhar quais incômodos teve ao usar o editor Slate?
Eu só usei o Tiptap, mas ouvi dizer que o Slate é bom, então fiquei interessado!!
A parte de criar componentes externos é bem mais prática. Especialmente quando, como no React, se usa um DOM próprio, é preciso renderizar como componente em vez de HTML, e o tiptap, que já foi feito pensando em modularização desde o início, achei bem mais fácil de ajustar.
No geral, achei a documentação do Slate difícil, e por ser muito raw, senti que havia ainda mais coisas para aprender para implementar os recursos que eu queria.
Como é uma lembrança de uns 2 anos atrás, pode ser que esteja um pouco diferente, mas passei por problemas como estes.
Problema de entrada em coreano no ambiente mobile: foi muito difícil encontrar onde isso estava acontecendo; surgiu enquanto eu fazia customizações, então não lembro exatamente.
Dificuldade com controles relacionados a seleção: foi extremamente complicado adicionar um recurso para tratar atributos dos caracteres selecionados. (o próprio objeto é complexo)
Dificuldade no desenvolvimento de plugins: tentei desenvolver diretamente plugins como o de mapa, mas o tiptap é estruturado de um jeito que facilita adicionar e desenvolver plugins, então foi confortável.
Pessoalmente, acho que a documentação é bem feita, mas há elementos que exigem assinatura paga misturados no meio.
Não chega a atrapalhar a leitura da documentação, mas é curioso e até um pouco irritante como isso dá vontade de assinar mesmo sem precisar... uma sensação meio complexa e ambígua.
Acho difícil concordar com a afirmação de que a documentação é razoavelmente boa. Na minha percepção, a distância entre a documentação de introdução e a documentação da API é grande demais, então a curva de aprendizado é alta. No projeto em React que estamos conduzindo, avaliamos que o estilo de documentação do Prosemirror e do react-prosemirror é mais amigável para o usuário e mais bem acabado, por isso escolhemos o react-prosemirror e não o tiptap.
Enquanto tentávamos entender os exemplos em React para criar um código de amostra de POC para os nossos requisitos, encontramos os seguintes problemas.
Quais elementos ficam disponíveis ao adicionar o StarterKit? É preciso procurar uma documentação separada pelo nome do pacote. Isso faz você perder o foco de simplesmente executar e testar os exemplos do tiptap.
O ListItem está incluído no StarterKit, então por que o exemplo inclui o ListItem no projeto de novo? Para configurar o extension.
Por que é preciso usar uma sintaxe como editor().chain().focus()? Não há explicação nem princípios de projeto sobre method chaining.
Bubble menu e Floating menu não aparecem no exemplo em React. Como o comportamento é diferente do recurso visto na página Try it live (https://templates.tiptap.dev/pjrwkQtNpq), é preciso ir à documentação para entender por que essas funcionalidades estão faltando.
Não há funcionalidade de tabela, então você pesquisa pela palavra-chave table na página Extensions. Nos resultados aparecem Table, TableCell, TableHeader e TableRow. Será que é preciso adicionar tudo isso?
De algum jeito, consegui adicionar Table e várias extensões. Para verificar se a funcionalidade está funcionando direito, primeiro é preciso inserir uma tabela. Como os comandos da toolbar devem ser escritos? Em que parte da toolbar do editor devem ser adicionadas as funções referentes a esses comandos? Não há absolutamente nenhuma pista.
Há um requisito de que não deve ser possível aninhar outra tabela dentro de uma tabela. Como implementar a lógica para determinar se o cursor está dentro de uma tabela? Não há absolutamente nenhuma pista.
Lembro que o Color estava empacotado como extension e, por curiosidade, abro o código-fonte. Ao ver que há apenas dois arquivos no diretório src, só consigo suspirar. Não consigo entender a intenção de ter criado módulos tão pequenos assim. Se até funcionalidades tão pequenas viram pacotes, isso não aumenta a carga de gerenciamento de versões de dependências mais do que a reutilização?
É difícil para mim concordar com os pontos 1-3, 4-6 e 8, porque não senti nenhuma dúvida nem incômodo em relação a eles.
1-2
O StarterKit é, literalmente, um kit para começar, então me parece que ele perde bastante relevância no momento de uso real.
No caso do ListItem, é como você disse. É um elemento para configurar a extensão Color. Da mesma forma, acho que basta não usar o StarterKit se isso incomodar.
3 chain().something().run() é basicamente um tipo de açúcar sintático, mas acho que oferece uma funcionalidade que combina bem com o conceito de uma biblioteca batteries-included.
Tenho usado isso de forma muito útil em ambientes mobile, onde ações como aplicar negrito e depois focar são praticamente essenciais.
4
Como não uso essa funcionalidade, não sei dizer muito bem.
(Acho que isso também traz uma vantagem em contrapartida à desvantagem que você mencionou no ponto 1, sobre sair do estado de foco, já que não é preciso ver informações sobre funcionalidades que eu não vou usar.)
5-6
Além de isso estar bem documentado na documentação de cada extensão, no geral não há absolutamente nada de diferente em relação à implementação comum de um editor.
Sinceramente, no ponto 6 eu nem tenho certeza se entendi corretamente o que o savvykang quis dizer... Fico pensando direto algo como: “Por que isso seria uma dúvida...? Que tipo de pista estaria faltando...?” haha...
7
"Assim como nas outras coisas de outros nós", é possível verificar o foco com editor.isActive('table').
Mas acho que isso não é um problema que se resolve apenas identificando o nó em foco. Parece ser um requisito que exige considerar várias coisas, como filtragem de colagem, inserção via ferramentas de desenvolvedor etc.
8
Concordo com a parte sobre isso aumentar a carga de gerenciamento de versões das dependências, mas também acho que há a vantagem de não precisar carregar código de funcionalidades desnecessárias.
No nosso caso, era exatamente uma situação em que não usaríamos a extensão Color que você mencionou. Acho que cada abordagem tem seus prós e contras.
.
Acho que o react-prosemirror e o tiptap que você mencionou têm conceitos completamente diferentes.
um cara que permite usar o prosemirror de forma mais idiomática no React
vs
um cara em que pouco importa se é baseado em prosemirror ou não, e que de todo modo reúne tudo o que é necessário para implementar um editor que combine com o meu serviço
Como ele já é bem popular no lado do Vue, fiquei na dúvida se valia a pena escrever sobre isso,
mas desta vez apliquei e usei no SvelteKit, gostei bastante do resultado e resolvi compartilhar.
No ecossistema do Svelte, eu estava preocupado porque não havia um editor WYSIWYG realmente satisfatório do tipo “é isso!”,
então, se houver outras pessoas com a mesma dúvida, acho que vale a pena tentar pelo menos uma vez.
9 comentários
Pessoalmente, dos que usei, este pareceu o mais confortável e o mais fácil de expandir.
Muitas das dificuldades que senti ao criar um editor com o Slate foram realmente resolvidas aqui.
Por acaso você poderia compartilhar quais incômodos teve ao usar o editor Slate?
Eu só usei o Tiptap, mas ouvi dizer que o Slate é bom, então fiquei interessado!!
A parte de criar componentes externos é bem mais prática. Especialmente quando, como no React, se usa um DOM próprio, é preciso renderizar como componente em vez de HTML, e o
tiptap, que já foi feito pensando em modularização desde o início, achei bem mais fácil de ajustar.No geral, achei a documentação do Slate difícil, e por ser muito raw, senti que havia ainda mais coisas para aprender para implementar os recursos que eu queria.
Como é uma lembrança de uns 2 anos atrás, pode ser que esteja um pouco diferente, mas passei por problemas como estes.
Oh... muito obrigado~!
Você pode conferir um exemplo funcional do editor em https://tiptap.dev/docs/editor/installation/react#7-the-complete-setup.
Pessoalmente, acho que a documentação é bem feita, mas há elementos que exigem assinatura paga misturados no meio.
Não chega a atrapalhar a leitura da documentação, mas é curioso e até um pouco irritante como isso dá vontade de assinar mesmo sem precisar... uma sensação meio complexa e ambígua.
Acho difícil concordar com a afirmação de que a documentação é razoavelmente boa. Na minha percepção, a distância entre a documentação de introdução e a documentação da API é grande demais, então a curva de aprendizado é alta. No projeto em React que estamos conduzindo, avaliamos que o estilo de documentação do Prosemirror e do react-prosemirror é mais amigável para o usuário e mais bem acabado, por isso escolhemos o react-prosemirror e não o tiptap.
Enquanto tentávamos entender os exemplos em React para criar um código de amostra de POC para os nossos requisitos, encontramos os seguintes problemas.
editor().chain().focus()? Não há explicação nem princípios de projeto sobre method chaining.src, só consigo suspirar. Não consigo entender a intenção de ter criado módulos tão pequenos assim. Se até funcionalidades tão pequenas viram pacotes, isso não aumenta a carga de gerenciamento de versões de dependências mais do que a reutilização?É difícil para mim concordar com os pontos 1-3, 4-6 e 8, porque não senti nenhuma dúvida nem incômodo em relação a eles.
1-2
O StarterKit é, literalmente, um kit para começar, então me parece que ele perde bastante relevância no momento de uso real.
No caso do ListItem, é como você disse. É um elemento para configurar a extensão Color. Da mesma forma, acho que basta não usar o StarterKit se isso incomodar.
3
chain().something().run()é basicamente um tipo de açúcar sintático, mas acho que oferece uma funcionalidade que combina bem com o conceito de uma biblioteca batteries-included.Tenho usado isso de forma muito útil em ambientes mobile, onde ações como aplicar negrito e depois focar são praticamente essenciais.
4
Como não uso essa funcionalidade, não sei dizer muito bem.
(Acho que isso também traz uma vantagem em contrapartida à desvantagem que você mencionou no ponto 1, sobre sair do estado de foco, já que não é preciso ver informações sobre funcionalidades que eu não vou usar.)
5-6
Além de isso estar bem documentado na documentação de cada extensão, no geral não há absolutamente nada de diferente em relação à implementação comum de um editor.
Sinceramente, no ponto 6 eu nem tenho certeza se entendi corretamente o que o savvykang quis dizer... Fico pensando direto algo como: “Por que isso seria uma dúvida...? Que tipo de pista estaria faltando...?” haha...
7
"Assim como nas outras coisas de outros nós", é possível verificar o foco com
editor.isActive('table').Mas acho que isso não é um problema que se resolve apenas identificando o nó em foco. Parece ser um requisito que exige considerar várias coisas, como filtragem de colagem, inserção via ferramentas de desenvolvedor etc.
8
Concordo com a parte sobre isso aumentar a carga de gerenciamento de versões das dependências, mas também acho que há a vantagem de não precisar carregar código de funcionalidades desnecessárias.
No nosso caso, era exatamente uma situação em que não usaríamos a extensão Color que você mencionou. Acho que cada abordagem tem seus prós e contras.
.
Acho que o react-prosemirror e o tiptap que você mencionou têm conceitos completamente diferentes.
um cara que permite usar o prosemirror de forma mais idiomática no React
vs
um cara em que pouco importa se é baseado em prosemirror ou não, e que de todo modo reúne tudo o que é necessário para implementar um editor que combine com o meu serviço
Como ele já é bem popular no lado do Vue, fiquei na dúvida se valia a pena escrever sobre isso,
mas desta vez apliquei e usei no SvelteKit, gostei bastante do resultado e resolvi compartilhar.
No ecossistema do Svelte, eu estava preocupado porque não havia um editor WYSIWYG realmente satisfatório do tipo “é isso!”,
então, se houver outras pessoas com a mesma dúvida, acho que vale a pena tentar pelo menos uma vez.