في الآونة الأخيرة، بدأت في التحقيق في خطأ يتعلق بإضافة Events، حيث تُفقد بيانات الأحداث المعروضة في محرر المنشور إذا تم حفظ المنشور كمسودة.
حاولت إصلاح المشكلة، واكتشفت قريبًا أنه لا توجد واجهة برمجة تطبيقات (API) مكشوفة من قبل Discourse تسمح لنا بذلك.
أعتقد أن هذه ميزة مهمة من منظور تجربة المستخدم (UX)، ولها العديد من حالات الاستخدام المحتملة بخلاف ما أواجهه أنا.
لذلك، أقوم بإنشاء طلب سحب (PR) يحل هذه المشكلة من خلال إضافة طريقة جديدة في نموذج Composer تسمى serializeToDraft. ستضيف هذه الطريقة الحقول المخصصة عند حفظ المنشور كمسودة. كما سيتم تعيين هذه الحقول لنموذج Composer عند إعادة فتح المسودة.
يساعدني @angus في هذا الطلب السحب من خلال مراجعة الكود واقتراح التحسينات المهمة التي يجب إجراؤها.
هناك بعض الأمور التي لا أفهمها: لماذا تُعد serializeToDraft جزءًا من واجهة برمجة التطبيقات للإضافة بينما serializeOnCreate وserializeToTopic ليست كذلك؟ في أي ظرف تكون serializeToDraft مفيدة دون الوظيفتين الأخريين، والعكس صحيح؟ ألا يجب أن يكون هناك غلاف يقوم بالتسلسل في كل من المنشور/الموضوع وفي المسودة أيضًا؟
لقد صادفت مشكلة أخرى: ماذا عن طريقة saveDraft()؟ يجب أن يكون هناك مراقب للحقول المضافة عبر serializeToDraft()، مشابه لهذا:
وإلا فلن يتم إرسال المسودة إلى نقطة النهاية إذا تغيرت فقط حقول المسودة المخصصة.
لذلك يجب أن تكون saveDraft() جزءًا من الواجهة البرمجية، أو في الواقع يجب إخفاء هذا الأمر بطريقة ما.
لقد وجدت أيضًا مراقب dataChanged هذا في نموذج المصنف. أعتقد أنه غريب جدًا أن يكون لدينا مراقبان يراقبان نفس الشيء. من المرجح أن المنطق داخل هذا المراقب يحتاج أيضًا إلى تنفيذه لحقول المسودة المخصصة. كما أتساءل أي من المراقبين سيعمل أولاً وما هي الآثار المترتبة على ذلك.