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

開発
1

Recently, I started looking into a bug with the Events plugin where the events data shown on the composer is lost if the post is saved to drafts.

I tried to fix the issue and soon found out that there’s no API exposed by Discourse which allows us to do that.

I think this is an important feature from a UX standpoint with many potential use cases other than what I’m faced with.

For that, I am making a PR, which fixes this issue by introducing a new method in the Composer Model called serializeToDraft. This method will add those custom fields while saving the post to draft. Also, those fields will be set to the composer model when the draft is reopened.

@angus is helping me out on this PR by reviewing the code and suggesting the important improvements to be made.

I would like to know the thoughts of the Discourse team on this feature.

「いいね！」 2
2

I agree we should have a clean mechanism for plugins to add and retrieve draft info associated with a post.

「いいね！」 3
3

Me and @angus have put together a PR to address this here.

「いいね！」 6
4

There are some things I dont understand: why is serializeToDraft part of the plugin api while serializeOnCreate and serializeToTopic are not? under what circumstance is serializeToDraft useful without the other two and vice versa? shouldnt there be a wrapper that does the serialization on both post/topic and also the draft?

「いいね！」 3
5

Yes, agreed. You can go ahead and make a PR for those ones too.

6

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

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

「いいね！」 1