Vor kurzem habe ich mich mit einem Fehler im Events-Plugin beschäftigt, bei dem die auf dem Composer angezeigten Event-Daten verloren gehen, wenn der Beitrag als Entwurf gespeichert wird.
Ich habe versucht, das Problem zu beheben und stellte bald fest, dass es keine von Discourse bereitgestellte API gibt, die uns dies ermöglicht.
Ich halte dies aus UX-Sicht für eine wichtige Funktion mit vielen potenziellen Anwendungsfällen, die über meinen aktuellen Fall hinausgehen.
Daher erstelle ich einen PR, der dieses Problem behebt, indem eine neue Methode namens serializeToDraft im Composer-Modell eingeführt wird. Diese Methode fügt beim Speichern des Beitrags als Entwurf diese benutzerdefinierten Felder hinzu. Außerdem werden diese Felder beim erneuten Öffnen des Entwurfs im Composer-Modell gesetzt.
@angus unterstützt mich bei diesem PR, indem er den Code überprüft und wichtige Verbesserungen vorschlägt.
Ich würde gerne die Meinung des Discourse-Teams zu dieser Funktion hören.
Ich stimme zu, dass wir einen sauberen Mechanismus für Plugins benötigen, um Entwurfsinformationen, die einem Beitrag zugeordnet sind, hinzuzufügen und abzurufen.
Es gibt einige Dinge, die ich nicht verstehe: Warum ist serializeToDraft Teil der Plugin-API, während serializeOnCreate und serializeToTopic nicht dazu gehören? Unter welchen Umständen ist serializeToDraft ohne die beiden anderen nützlich und umgekehrt? Sollte es nicht einen Wrapper geben, der die Serialisierung sowohl für Post/Topic als auch für den Entwurf übernimmt?
Ich bin auf ein weiteres Problem gestoßen: Was ist mit der saveDraft()-Methode? Irgendwie muss es einen Observer für die mit serializeToDraft() hinzugefügten Felder geben, ähnlich wie hier:
Andernfalls wird der Entwurf nicht an den Endpunkt gesendet, wenn sich nur die benutzerdefinierten Entwurfsfelder ändern.
Also sollte saveDraft() ebenfalls Teil der API sein, oder eigentlich sollte dies auf irgendeine Weise abstrahiert werden.
Ich habe auch diesen dataChanged-Observer im composerModel gefunden. Es erscheint mir sehr seltsam, dass wir zwei Observer haben, die dasselbe überwachen. Die Logik innerhalb dieses Observers müsste wahrscheinlich auch für die benutzerdefinierten Entwurfsfelder ausgelöst werden. Ich frage mich auch, welcher der beiden Observer zuerst ausgeführt wird und welche Auswirkungen das hat.