Including composer custom fields on save draft

개발
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

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

3

저와 @angus가 이 문제를 해결하기 위해 PR을 만들었습니다.

4

몇 가지 이해되지 않는 부분이 있습니다: 왜 serializeToDraft는 플러그인 API의 일부인 반면, serializeOnCreate와 serializeToTopic은 그렇지 않나요? 나머지 두 메서드가 없는 상황에서 serializeToDraft가 유용한 경우는 언제이며, 그 반대는 어떨까요? 포스트/토픽과 초안 모두에서 직렬화를 수행하는 래퍼가 있어야 하지 않나요?

5

네, 동의합니다. 그것들도 PR을 올려주세요.

6

또 다른 문제를 발견했습니다: saveDraft() 메서드는 어떻게 처리해야 하나요? serializeToDraft()로 추가된 필드에 대해 이 링크와 유사한 옵저버가 필요합니다:

그렇지 않으면 커스텀 초안 필드만 변경된 경우 초안이 엔드포인트로 전송되지 않습니다.
따라서 saveDraft()도 API의 일부가 되어야 하거나, 실제로는 이 부분이 어떻게든 추상화되어야 합니다.
또한 composermodel에서 dataChanged 옵저버를 발견했습니다. 같은 것을 감시하는 두 개의 옵저버가 있다는 것은 매우 이상하다고 생각합니다. 이 옵저버 내부의 로직은 커스텀 초안 필드에 대해서도 트리거되어야 할 가능성이 높습니다. 또한 두 옵저버 중 어느 쪽이 먼저 실행되는지, 그리고 그 영향이 무엇인지도 궁금합니다.