Recentemente, comecei a investigar um bug no plugin Events, onde os dados dos eventos exibidos no editor são perdidos se a postagem for salva como rascunho.
Tentei corrigir o problema e logo descobri que não há uma API exposta pelo Discourse que permita fazer isso.
Acredito que essa seja uma funcionalidade importante do ponto de vista da UX, com muitos casos de uso potenciais além daquele que estou enfrentando.
Por isso, estou abrindo um PR que resolve esse problema ao introduzir um novo método no Modelo do Editor chamado serializeToDraft. Esse método adicionará esses campos personalizados ao salvar a postagem como rascunho. Além disso, esses campos serão carregados no modelo do editor quando o rascunho for reaberto.
@angus está me ajudando com esse PR, revisando o código e sugerindo as melhorias importantes a serem feitas.
Gostaria de saber a opinião da equipe do Discourse sobre essa funcionalidade.
Há algumas coisas que não entendo: por que serializeToDraft faz parte da API do plugin, enquanto serializeOnCreate e serializeToTopic não? Em que circunstâncias serializeToDraft é útil sem os outros dois, e vice-versa? Não deveria haver um wrapper que realize a serialização tanto no post/tópico quanto no rascunho?
Encontrei outro problema: e o método saveDraft()? De alguma forma, precisa haver um observador para os campos adicionados com serializeToDraft(), semelhante a este:
caso contrário, o rascunho não será enviado ao endpoint se apenas os campos de rascunho personalizados forem alterados.
Portanto, saveDraft() também deveria fazer parte da API ou, na verdade, isso deveria ser abstraído de alguma forma.
Também encontrei esse observador dataChanged no composermodel. Acho muito estranho termos dois observadores monitorando a mesma coisa. A lógica dentro desse observador provavelmente também precisaria ser acionada para os campos de rascunho personalizados. Também me pergunto qual dos dois observadores será executado primeiro e quais são as implicações disso.