下書き保存時にComposerのカスタムフィールドを含める

開発
1

最近、Events プラグインのバグ調査を開始しました。投稿を下書きとして保存すると、コンポーザーに表示されるイベントデータが失われる問題です。

この問題を修正しようと試みたところ、Discourse 側でそのような処理を可能にする API が公開されていないことがわかりました。

これは UX の観点から重要な機能であり、私が直面している状況以外にも多くのユースケースが考えられます。

そこで、コンポーザーモデルに serializeToDraft という新しいメソッドを追加することでこの問題を解決する PR を作成しました。このメソッドは、投稿を下書きとして保存する際にこれらのカスタムフィールドを追加します。また、下書きを再度開いた際には、これらのフィールドがコンポーザーモデルに設定されます。

@angus には、コードレビューや重要な改善点の提案を通じてこの PR のサポートをいただいています。

Discourse チームのこの機能に対するご意見をお聞かせください。

2

プラグインが投稿に関連する下書き情報を追加・取得するための明確な仕組みを導入すべきだという点に同意します。

3

私と @angus がこの問題に対処するための PR を作成しました。

4

いくつか理解できない点があります：なぜ serializeToDraft はプラグイン API に含まれているのに、serializeOnCreate と serializeToTopic は含まれていないのでしょうか？他の 2 つなしで serializeToDraft が役立つのはどのような状況なのでしょうか？また、その逆は？ポストとトピック、そして下書きの両方でシリアライズを行うラッパーがあってもよいのではないでしょうか？

5

はい、同意します。それらについても PR を作成して問題ありません。

6

別の問題に気づきました：saveDraft() メソッドはどうなるのでしょうか？serializeToDraft() で追加されたフィールドには、以下のようなオブザーバーが必要になるはずです。

カスタムドラフトフィールドのみが変更された場合、ドラフトがエンドポイントに送信されないためです。
したがって、saveDraft() も API の一部にするか、あるいは何らかの方法で抽象化する必要があります。
また、composermodel 内の dataChanged オブザーバーも見つけました。同じものを監視するオブザーバーが 2 つあるのは非常に奇妙だと思います。このオブザーバー内のロジックは、カスタムドラフトフィールドに対しても同様にトリガーされる必要があるでしょう。どちらのオブザーバーが先に実行され、その影響は何かという点も気になります。