Récemment, j’ai commencé à investiguer un bug dans le plugin Events où les données des événements affichées dans le compositeur sont perdues si le message est enregistré en brouillon.
J’ai essayé de corriger le problème et j’ai rapidement découvert qu’aucune API n’était exposée par Discourse pour nous permettre de le faire.
Je pense qu’il s’agit d’une fonctionnalité importante d’un point de vue UX, avec de nombreux cas d’utilisation potentiels autres que celui auquel je suis confronté.
Pour cette raison, je soumets une PR qui résout ce problème en introduisant une nouvelle méthode dans le modèle Composer appelée serializeToDraft. Cette méthode ajoutera ces champs personnalisés lors de l’enregistrement du message en brouillon. De plus, ces champs seront réinitialisés dans le modèle du compositeur lorsque le brouillon sera rouvert.
@angus m’aide sur cette PR en examinant le code et en suggérant les améliorations importantes à apporter.
J’aimerais connaître l’avis de l’équipe Discourse sur cette fonctionnalité.
Je suis d’accord, nous devrions avoir un mécanisme propre permettant aux plugins d’ajouter et de récupérer les informations de brouillon associées à un article.
Il y a certaines choses que je ne comprends pas : pourquoi serializeToDraft fait-il partie de l’API du plugin alors que serializeOnCreate et serializeToTopic ne le sont pas ? Dans quelles circonstances serializeToDraft est-il utile sans les deux autres, et inversement ? Ne devrait-il pas exister un wrapper qui gère la sérialisation à la fois pour les publications/sujets et pour les brouillons ?
Je suis tombé sur un autre problème : qu’en est-il de la méthode saveDraft() ? Il faut de toute façon ajouter un observateur pour les champs ajoutés via serializeToDraft(), similaire à celui-ci :
Sinon, le brouillon ne sera pas envoyé au point de terminaison si seuls les champs de brouillon personnalisés changent.
Donc, saveDraft() devrait également faire partie de l’API, ou alors cela devrait être abstrait d’une manière ou d’une autre.
J’ai également trouvé cet observateur dataChanged dans composermodel. Je trouve très étrange que nous ayons deux observateurs surveillant la même chose. La logique à l’intérieur de cet observateur devrait probablement également être déclenchée pour les champs de brouillon personnalisés. Je me demande aussi lequel des deux observateurs s’exécutera en premier et quelles en seront les implications.