Incluir campos personalizados de Composer al guardar borrador

Recientemente, empecé a investigar un error en el plugin de Eventos donde los datos de los eventos mostrados en el editor se pierden si la publicación se guarda como borrador.

Intenté solucionar el problema y pronto descubrí que no existe una API expuesta por Discourse que nos permita hacerlo.

Creo que esta es una función importante desde el punto de vista de la experiencia de usuario, con muchos casos de uso potenciales además del que yo enfrento.

Por ello, estoy presentando una PR que soluciona este problema introduciendo un nuevo método en el Modelo del Editor llamado serializeToDraft. Este método agregará esos campos personalizados al guardar la publicación como borrador. Además, esos campos se establecerán en el modelo del editor cuando se vuelva a abrir el borrador.

@angus me está ayudando en esta PR revisando el código y sugiriendo las mejoras importantes que deben realizarse.

Me gustaría conocer la opinión del equipo de Discourse sobre esta función.

Estoy de acuerdo en que deberíamos tener un mecanismo limpio para que los complementos agreguen y recuperen información de borrador asociada a una publicación.

@angus y yo hemos preparado un PR para abordar esto aquí.

Hay algunas cosas que no entiendo: ¿por qué serializeToDraft forma parte de la API del plugin, mientras que serializeOnCreate y serializeToTopic no lo son? ¿En qué circunstancia es útil serializeToDraft sin los otros dos, y viceversa? ¿No debería haber un envoltorio que realice la serialización tanto en la publicación/tema como en el borrador?

Sí, de acuerdo. Puedes proceder a crear un PR para esos también.

Me encontré con otro problema: ¿qué hay del método saveDraft()? De alguna manera, debe haber un observador para los campos agregados con serializeToDraft(), similar a este:

De lo contrario, el borrador no se enviará al endpoint si solo cambian los campos de borrador personalizados.
Por lo tanto, saveDraft() también debería formar parte de la API, o en realidad esto debería abstraerse de alguna manera.
También encontré este observador dataChanged en composermodel. Creo que es muy extraño que tengamos dos observadores vigilando lo mismo. La lógica dentro de este observador probablemente también debería activarse para los campos de borrador personalizados. También me pregunto cuál de los dos observadores se ejecutará primero y cuáles son las implicaciones.