 |
ملخص | النقر في منطقة النص في المنشئ سيحدد السطر المقابل في جزء المعاينة، والعكس صحيح. |
 |
رابط المستودع | \u003chttps://github.com/thijsbrilleman/discourse-click-to-edit\u003e |
 |
دليل التثبيت | كيفية تثبيت الإضافات في Discourse |
النقر في منطقة النص في المنشئ سيحدد السطر المقابل في جزء المعاينة، والعكس صحيح.
إضافة رائعة جدًا إلى التحرير الأساسي لـ Discourse. شكراً لك على إنشائها.
يبدو أنه شيء يجب الترحيب به، على الرغم من أنه ليس لدي رأي في ذلك.
مرحباً 
شكراً، هذا رائع حقاً 
أفكر فقط أنه سيكون من الرائع جعله كمكون سمة. 
شكراً لك، وأنا أتفق معك. سألقي نظرة عليه بمجرد أن يتوفر لدي الوقت. نرحب بك دائماً لتقديم طلب سحب.
هذا هو السلوك المقصود حالياً، لكنني بالطبع منفتح على أفكار أفضل. ما نوع التلميح المرئي الذي توصي به؟
كان سيظهر كنص منسوخ عند تحديد شيء ما بالفعل. ثم سيكون هناك إجراء ورد فعل.
فضولي، لماذا هذا مكون إضافي مقابل مكون سمة؟ لا يمكن إنشاء كل هذه الرموز من جانب العميل؟
عمل رائع بالمناسبة، أحب أنك تعتمد على أرقام الأسطر التي يولدها محرك الترميز.
شكراً لك سام.
كما قد تكون لاحظت، فإن سمات data-ln موجودة في HTML المُعالج الذي تم إنشاؤه وتخزينه على الخادم أيضًا.
لقد طبقت هذا السلوك، حتى أتمكن لاحقًا من توسيع المكون الإضافي للسماح بالإدراج/التحرير الموثوق به للأجزاء من صفحة عرض الموضوع، وهو ما يعادل زر التحرير المعروض أدناه (ولكنه أكثر قوة قليلاً):
لقد مر عام منذ أن كتبته، ولكن إذا كنت أتذكر بشكل صحيح، لهذا الغرض في plugin.rb السطر
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
مطلوب للتأكد من أن امتداد MarkdownIt يعمل أيضًا من جانب الخادم عند معالجة HTML.
لم أجد الوقت اللازم لتطبيق ميزة التحرير الموسعة، لذلك إذا تم إسقاط هذا المتطلب، فيمكن تحويله إلى مكون على ما أعتقد.
@sam أنا أبحث في تحويله إلى مكون سمة، لكنني غير قادر على معرفة كيفية تنفيذ هذا الرمز في سياق مكون إضافي لـ markdownit:
// javascripts/lib/discourse-markdown/initialize_markdownit_plugin.js:
export function setup(helper) {
helper.registerPlugin(markdownitLineNumbers); // markdownitLineNumbers متاح بالفعل
}
لدي شك في أن السطر في المكون الإضافي الذي كتبته سابقًا يرش بعض السحر من جانب العميل أيضًا:
# plugin.rb
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text`
هل لديك أي فكرة؟
لست متأكدًا، سأتواصل مع الفريق.
أعتقد أن هذا يرجع إلى أنه مقيد حاليًا بنطاق الإضافات فقط. سيعمل بدون هذا الفحص. (تم تقديم هذا الرمز في هذا الالتزام)
أردت دمج أرقام الأسطر لمكون آخر، لكنني لم أرغب في إنشاء إضافة، لذلك تراجعت عن ذلك. سيكون رائعًا جدًا إذا كان يمكن دعم ميزات markdown في مكونات الثيم!
على صعيد آخر، ميزة رائعة اقترحتها هنا – لطيفة جدًا. 
آه نعم، هذا يوضح الأمر.
بالنظر إلى هذا الكود، قد يكون من الممكن حقن مكون الماركداون يدويًا من مكون السمة في وقت التشغيل، ولكن هذا سيكون حلاً تقنيًا للغاية. سأنتظر قرار الفريق الأساسي قبل محاولة تنفيذه.
تعمل خطوط أنابيب ماركداون الخاصة بنا على كل من العميل (للمعاينة) وعلى الخادم (لعرض HTML مسبقًا للمنشورات). لهذا السبب تم تصميمه للمكونات الإضافية فقط - فهي الوحيدة التي يمكنها حقن التعليمات البرمجية من جانب الخادم.
الآن… هذه الحالة غير عادية للغاية، نظرًا لأن الامتداد مطلوب فقط في المنشئ، وليس على الخادم. لذلك، يجب أن يكون القيام بذلك من مكون سمة ممكنًا.
هل كانت لديك استراتيجية معينة في ذهنك لهذا؟
يبدو هذا شيئًا سيكون له جاذبية واسعة. قد يكون من الصعب العثور على مكانك في منشور طويل. هل يمكن أن يكون #pr-welcome؟
تجاوز هذه الوظيفة في قاعدة التعليمات البرمجية الأصلية:
// discourse/app/assets/javascripts/discourse/app/components/d-editor.js
async cachedCookAsync(text, options) {
this._cachedCookFunction ||= await generateCookFunction(options || {});
return await this._cachedCookFunction(text);
}
باستخدام مُهيئ لمكون سمة:
export default {
name: "d-editor-cached-cook-async-override",
initialize() {
const dEditor = require("discourse/components/d-editor").default;
dEditor.reopen({
cachedCookAsync(text, options) {
// تكرار التعليمات البرمجية هنا لإرجاع وظيفة طهي معدلة
},
});
},
};
سيعني ذلك قدرًا كبيرًا من تكرار التعليمات البرمجية، إذا كان سيعمل على الإطلاق. قذر، قذر.
حسنًا، أتفق - بالتأكيد ليس مثاليًا. قد لا يكون تكرار الكود ممكنًا حتى، لأن وحدات markdown-it يتم تحميلها بشكل غير متزامن، وليست جزءًا من نظام وحدات amd الذي تتمتع السمات/الإضافات بالوصول المباشر إليه. 
بناء نظام للسماح للسمات بالمساهمة في تحويلات md من جانب العميل فقط يمكن أن يكون رائعًا، على الرغم من أن حالات الاستخدام محدودة للغاية. في 99٪ من الحالات، يريد الناس أن يتم تطبيق تحويلات md من جانب الخادم أيضًا.
لذلك أعتقد، في الوقت الحالي، أن الالتزام بإضافة هو على الأرجح أفضل نهج.
أتساءل عما إذا كان يجب تطبيق هذا النوع من الزخرفة بغض النظر؟
مثال:
<p data-source-line="0">.....</p>
ستساعد سمة البيانات الإضافية الكثير من التطبيقات الداخلية لدينا، مثل، على سبيل المثال، عدم إظهار الإكمال التلقائي عندما تكون داخل كتلة رمز. كما أن الاقتباس والتحرير السريع يصبحان أسهل بكثير.
التنفيذ البسيط لا يحمل أي وزن إضافي تقريبًا، ولكنه يسمح لنا بحذف كومة من الشيفرة المصدرية.
كان لدينا هذا في الماضي (خلف علامة)، ولكن تم إزالته في هذا الالتزام. وجدت هذه لقطة الشاشة من بعض المناقشات الداخلية حول هذه الميزة:
أي أن مشكلة الأداء كانت مع رمز مزامنة التمرير، وليس حقن أرقام الأسطر 
لذا نعم، ليس لدي اعتراض على إضافة حقن مصدر البيانات في النواة، طالما أنه يضاف فقط في المعاينة. هل أنت مهتم بتقديم طلب سحب لهذا @pipkin؟
بكل سرور! يسعدني أن أتمكن من رد الجميل لكم.
