Backbone: يبني العمود الفقري مخصص

سيكون أمرا رائعا.

إذا كنت مهتمًا بكيفية تعديل قاعدة أكواد Backbone.js إلى نمط معياري ، فتحقق من مجلد customBuild داخل مفترق العمود الفقري الخاص بي. ضع في اعتبارك أن جميع اختبارات وحدة العمود الفقري لا تزال تجتاز بنجاح.
https://github.com/gfranko/backbone/tree/modularBuilds

أيضًا ، فيما يلي مثال على كيفية عمل واجهة مستخدم بناء مخصصة:
http://gregfranko.com/backbone/customBuild/

أخيرًا ، إليك منشور مدونة كتبته لمناقشة احتمال استخدام بعض أجزاء العمود الفقري فقط:
http://gregfranko.com/blog/backbone-dot-js-convincing-the-boss-guide/

أنا أقدر الفكرة حقًا ، لا سيما الجزء الذي اختفت فيه تبعيات الياقوت وأصبح النخر يلعب.

هناك أيضًا مواقف لا أحتاج فيها إلى Backbone.Router (لأنني لا أملك شيئًا ما للتوجيه ولكني ما زلت أرغب في استخدام Backbone لتنظيم JavaScript الخاص بي).

بالإضافة إلى ذلك ، يسير هذا بشكل جيد مع تصميمات LoDash (آه ، آمل ألا يشعر أحد بالغضب).

asciidisco لم أنجز العمل لدمج

gfranko هل ترغب في رؤية تطبيق jQuery مثل التنفيذ (نظرًا لأن 1.8 لديهم
ربما أقوم بتقسيم مشروعك وتجربته في نهاية هذا الأسبوع ، لكنني لست متأكدًا تمامًا مما إذا كان لدي وقت كافٍ :(

asciidisco لا تقلق بشأن ذلك. سوف ألقي نظرة على ملف jQuery grunt في نهاية هذا الأسبوع لأرى كيف يقومون بذلك.

: +1: لتشكيل قاعدة بيانات معيارية

بينما تكون الملفات المتعددة مفيدة غالبًا ، لا أعتقد أن العمود الفقري سيستفيد من تقسيم المصدر. المكتبة صغيرة نوعًا ما ، لذا ستوفر الإنشاءات المخصصة بضعة كيلوبايت فقط في أحسن الأحوال بينما يكون التعقيد الإضافي مهمًا.

لما يستحق ، نوقش هذا مرة واحدة على الأقل سابقًا في # 65.

ماذا عن حالات الاستخدام ، على سبيل المثال ، عندما يستخدم المستخدم jQuery Mobile مع Backbone.js ولا يريد تضمين مسارات العمود الفقري؟

أوافق على أن يظل مصدر العمود الفقري الافتراضي كملف واحد ، لكنني كنت أقترح أن تقسيم المصدر إلى ملفات متعددة (أدرك أن هذا يتطلب المزيد من العمل للمحافظة عليه) يمكن إضافته أيضًا في حالة عدم رغبة المستخدم في ميزة معينة.

أيضًا ، اقترحت في منشور مدونتي أن السماح للمستخدمين بعدم تضمين كل ميزة من ميزات Backbone سيجعل استخدام Backbone أسهل في بيئة الشركة.

ومما يثير الفضول فقط ، ما هو التعقيد الإضافي؟

ماذا عن حالات الاستخدام ، على سبيل المثال ، عندما يستخدم المستخدم jQuery Mobile مع Backbone.js ولا يريد تضمين مسارات العمود الفقري؟

فقط احذفه من المصدر. إنه موصوف بوضوح ويسهل القيام به.

ومما يثير الفضول فقط ، ما هو التعقيد الإضافي؟

أنا أشير إلى التعقيد بالنسبة للمساهمين الجدد والحاليين. دائمًا ما تكون كتابة التعليمات البرمجية لمشروع جديد أمرًا شاقًا ، ونريد تشجيعه قدر الإمكان. حاليًا ، يتطلب Backbone متصفحًا يخدم الملفات المحلية ومحرر نصوص. يعد طلب نظام / أداة بناء خطوة كبيرة للأمام.

ومع ذلك ، فأنا لا أعارض الإنشاءات المخصصة بشكل عام وأنا أفضل الأداة التي تقدمها في منشور المدونة الخاص بك. :)

أنت على حق ، كل كائن فئة Backbone محدد بشكل واضح (وهذا هو السبب في أنه كان من السهل جدًا بالنسبة لي تقسيم قاعدة التعليمات البرمجية). ومع ذلك ، لا أعتقد أن معظم المطورين يريدون لمس مصدر المكتبة التي يستخدمونها.

انظر إلى Require.js والنصوص البرمجية غير المتوافقة مع AMD كمثال. من السهل أن تلف lib داخل طريقة تعريف ، لكن من يريد أن يفعل ذلك؟

لكن نعم ، أسمع ما تقوله حول عدم محاولة إدخال الكثير من التبعيات / التعقيدات. أعتقد أنني سأحتفظ بهذا كمشروع منفصل وأبقي الكود محدثًا مع المصدر الأساسي.

نعم - أعتقد أنه مشروع رائع حقًا ... لكن العمود الفقري يستفيد من كونه نصًا بسيطًا واحدًا. إذا كان لديك Backbone مثبتًا ، فلديك فترة ، ويمكنك الاعتماد على كل ما يوفره متاحًا.

braddunbar: فقط احذفه من المصدر. إنه موصوف بوضوح ويسهل القيام به.

جاه ، إنه فخ! وجود نظام بناء رسمي لضمان الجودة والتوافق والوظائف بشكل أفضل.

jashkenas: نعم - أعتقد أنه مشروع أنيق حقًا ... لكن العمود الفقري يستفيد من كونه نصًا بسيطًا واحدًا.

يا ، أنا أحفر ملفات فردية أيضًا وهذا هو السبب في أن Lo-Dash هو ملف واحد ولكنه لا يزال يدعم الإنشاءات المخصصة (على الرغم من أن jQuery تجعله يعمل مع الملفات الفردية في الريبو الخاص به).

التصميمات المخصصة رائعة وتمنح المطورين مزيدًا من التحكم. مع Lo-Dash و jQuery التي تدعم الإنشاءات المخصصة ، فإن الشيء الوحيد المفقود هو Backbone ؛ د

مهلا،
إذا كان أي منكم مهتمًا ، فقد أنشأت مكونًا إضافيًا للحصول على تصميمات العمود الفقري المخصصة التي تم إنشاؤها من
ملفات مصدر العمود الفقري "العادية": https://github.com/asciidisco/grunt-backbonebuilder

لم يتم اختباره حقًا حتى الآن (على الرغم من أنني قمت بتشغيل إصدار العمود الفقري مع ترك جميع عناصر جهاز التوجيه والمحفوظات) ، والذي يعمل
حسنا. نرحب بالتعليقات.

asciidisco شكرًا لك ، أيها الروك!

سيكون من الرائع أن ننتقل إلى المتصفح أو حزمة الويب ، وبهذه الطريقة سيكون لدينا أفضل ما في العالمين (ملفات متعددة وملف واحد) بسهولة.

سيكون من الجيد أن يكون لديك Events كوحدة منفصلة. مفيد جدًا عند إنشاء وحدات مخصصة باستخدام تبعيات اختيارية Model s و Collection s.

أنا أستخدم نموذج العمود الفقري والمجموعة في مشروعي Angular و AngularJS. أنا بحاجة فقط إلى النموذج والمجموعة لأن المفهوم والمفهوم رائع. أنا أستخدمها كطبقة الوصول إلى البيانات. يوفر Angular طبقة واجهة المستخدم.

لقد كتبت مؤخرًا مقالًا حول كيفية الاستفادة من استخدام BackboneJS في تطبيق Angular: https://docs.google.com/document/d/1ptYmQzjq8EWLKyqFENqyXwzz67VNWzh_-clhy4W5R40

سيكون من الرائع حقًا تقسيم BackboneJS إلى عدة مكونات بحيث يمكنك تضمين العناصر التي تحتاجها فقط.

jashkenas ماذا عن تقسيم ملفات src إلى ملفات متعددة والسماح لمهمة

• ملف واحد بسيط
• وتقسيم ملفات المصدر
  ؟