javascript تحميل - أفضل الممارسات المقبولة الشائعة حول تنظيم الرموز في JavaScript




14 Answers

سيكون الأمر ألطف بكثير إذا كان جافا سكريبت تحتوي على مساحات أسماء ، لكنني أجد أن تنظيم أشياء مثل دوستين دياز يصف here يساعدني كثيراً.

var DED = (function() {

    var private_var;

    function private_method()
    {
        // do stuff here
    }

    return {
        method_1 : function()
            {
                // do stuff here
            },
        method_2 : function()
            {
                // do stuff here
            }
    };
})();

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

جافا سكريبت

نظرًا لأن إطارات جافا سكريبت مثل jQuery تجعل تطبيقات الويب من جانب العميل أكثر ثراءً وفاعلية ، فقد بدأت نلاحظ مشكلة واحدة ...

كيف تقوم بتنظيم هذا في العالم؟

  • ضع كل معالجاتك في مكان واحد واكتب وظائف لجميع الأحداث؟
  • إنشاء وظيفة / فئات لتغليف جميع وظائفك؟
  • اكتب كالمجانين ، وآمل أن يعمل على الأفضل؟
  • التخلي والحصول على مهنة جديدة؟

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

هل هناك أي توصيات عامة حول أفضل طريقة للحفاظ على ملفاتك .js لطيفة وأنيقة كبقية طلبك؟ أم أنها مجرد مسألة IDE؟ هل هناك خيار أفضل هناك؟

تصحيح

كان المقصود من هذا السؤال أن يكون أكثر حول تنظيم التعليمات البرمجية وليس تنظيم الملفات. كانت هناك بعض الأمثلة الجيدة على دمج الملفات أو تقسيم المحتوى.

سؤالي هو: ما هي طريقة أفضل الممارسات المقبولة حاليًا الشائعة لتنظيم شفرتك الفعلية؟ ما هي طريقتك ، أو حتى طريقة موصى بها للتفاعل مع عناصر الصفحة وإنشاء شفرة قابلة لإعادة الاستخدام لا تتعارض مع بعضها البعض؟

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




يمكنك تفكيك البرامج النصية الخاصة بك إلى ملفات منفصلة للتطوير ، ثم قم بإنشاء نسخة "إصدار" حيث تقوم بإلزامهم جميعًا معًا وتشغيل YUI Compressor أو ما شابه ذلك.




تتطلب منظمة الرمز اعتماد معايير ومعايير التوثيق:
1. رمز Namespace لملف فعلي ؛

Exc = {};


2. فئات المجموعة في مساحات الأسماء هذه javascript؛
3- وضع نماذج أو وظائف أو فئات ذات صلة لتمثيل الأشياء في العالم الحقيقي ؛

Exc = {};
Exc.ui = {};
Exc.ui.maskedInput = function (mask) {
    this.mask = mask;
    ...
};
Exc.ui.domTips = function (dom, tips) {
    this.dom = gift;
    this.tips = tips;
    ...
};


4. تعيين اصطلاحات لتحسين الكود. على سبيل المثال ، تجميع كل وظائفها الداخلية أو طريقتها في سمة صنفها لنوع الكائن.

Exc.ui.domTips = function (dom, tips) {
    this.dom = gift;
    this.tips = tips;
    this.internal = {
        widthEstimates: function (tips) {
            ...
        }
        formatTips: function () {
            ...
        }
    };
    ...
};


5. جعل وثائق مساحات الأسماء ، الطبقات ، الطرق والمتغيرات. عند الضرورة أيضا مناقشة بعض التعليمات البرمجية (بعض FIs و Fors ، فإنها تنفذ عادة منطق مهم من التعليمات البرمجية).

/**
  * Namespace <i> Example </i> created to group other namespaces of the "Example".  
  */
Exc = {};
/**
  * Namespace <i> ui </i> created with the aim of grouping namespaces user interface.
  */
Exc.ui = {};

/**
  * Class <i> maskdInput </i> used to add an input HTML formatting capabilities and validation of data and information.
  * @ Param {String} mask - mask validation of input data.
  */
Exc.ui.maskedInput = function (mask) {
    this.mask = mask;
    ...
};

/**
  * Class <i> domTips </i> used to add an HTML element the ability to present tips and information about its function or rule input etc..
  * @ Param {String} id - id of the HTML element.
  * @ Param {String} tips - tips on the element that will appear when the mouse is over the element whose identifier is id <i> </i>.
  */
  Exc.ui.domTips = function (id, tips) {
    this.domID = id;
    this.tips = tips;
    ...
};


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




لقد تمكنت من تطبيق نمط وحدة جافا سكريبت بنجاح على تطبيق Ext JS في مهمتي السابقة. قدمت طريقة بسيطة لإنشاء رمز مغلفة بشكل جيد.




تحقق من JavasciptMVC .

تستطيع :

  • تقسيم التعليمات البرمجية الخاصة بك إلى طبقات نموذج وعرض و تحكم.

  • ضغط كل رمز في ملف إنتاج واحد

  • لصناعة السيارات في توليد الكود

  • إنشاء وتشغيل اختبارات الوحدة

  • وغيرها الكثير...

أفضل من ذلك كله ، يستخدم jQuery ، لذلك يمكنك الاستفادة من الإضافات jQuery الأخرى أيضًا.




أنا مندهش لم يذكر أحد الأطر MVC. لقد تم استخدام Backbone.js modularize وفصل رمز بلدي ، وكان لا تقدر بثمن.

هناك عدد غير قليل من هذه الأنواع من الأطر هناك ، ومعظمها صغير جدا أيضا. رأيي الشخصي هو أنه إذا كنت ستكتب أكثر من مجرد زوجين من jQuery لأشياء UI مبهرج ، أو تريد تطبيق Ajax غني ، فإن إطار MVC سيجعل حياتك أسهل بكثير.




أنا خلق مفردات لكل شيء أنا حقا لست بحاجة إلى إنشاء عدة مرات على الشاشة ، ودروس لكل شيء آخر. ويتم وضع كل منهم في نفس مساحة الاسم في نفس الملف. كل شيء معلق ، ومصممة مع UML ، الرسوم البيانية للدولة. شفرة جافا سكريبت واضحة من html حتى لا javascript مضمّن وأنا أميل إلى استخدام jquery لتقليل مشاكل المتصفح المتقاطع.




قد يبدو تنظيم التعليمات البرمجية الخاصة بك في طريقة NameSpace المتمركزة في Jquery كما يلي ... ولن يتعارض مع واجهة برمجة التطبيقات الأخرى لـ Javascript مثل Prototype و Ext.

<script src="jquery/1.3.2/jquery.js" type="text/javascript"></script>
<script type="text/javascript">

var AcmeJQ = jQuery.noConflict(true);
var Acme = {fn: function(){}};

(function($){

    Acme.sayHi = function()
    {
        console.log('Hello');
    };

    Acme.sayBye = function()
    {
        console.log('Good Bye');
    };
})(AcmeJQ);

// Usage
//          Acme.sayHi();
// or
// <a href="#" onclick="Acme.sayHi();">Say Hello</a>


</script>

أتمنى أن يساعدك هذا.




أستخدم إدارة حزم Dojo ( dojo.require و dojo.provide ) ونظام الفصل ( dojo.declare الذي يسمح أيضًا بالوراثة المتعددة البسيطة) من أجل تقسيم جميع الطبقات / الأدوات إلى ملفات منفصلة. لا تجرِّف هذا فقط من تنظيم التعليمات البرمجية الخاصة بك ، ولكنها تسمح لك أيضًا بالقيام بالكسل / فقط في وقت تحميل الطبقات / الأدوات.




قم بإنشاء فئات مزيفة ، وتأكد من أن أي شيء يمكن طرحه في وظيفة منفصلة منطقية يتم ذلك. تأكد أيضا من التعليق كثيرا ، وعدم كتابة رمز spagghetti ، بدلا الاحتفاظ بها كلها في أقسام. على سبيل المثال ، بعض الرموز الفارغة التي تصور مُثلاتي. من الواضح في الحياة الواقعية أنا أكتب أيضا العديد من المكتبات التي تشمل أساسا وظائفها.

$(function(){
    //Preload header images
    $('a.rollover').preload();

    //Create new datagrid
    var dGrid = datagrid.init({width: 5, url: 'datalist.txt', style: 'aero'});
});

var datagrid = {
    init: function(w, url, style){
        //Rendering code goes here for style / width
        //code etc

        //Fetch data in
        $.get(url, {}, function(data){
            data = data.split('\n');
            for(var i=0; i < data.length; i++){
                //fetching data
            }
        })
    },
    refresh: function(deep){
        //more functions etc.
    }
};



أعتقد أن هذا يرتبط ، ربما ، DDD (تصميم يحركه المجال). التطبيق الذي أعمل عليه ، على الرغم من أنه يفتقر إلى واجهة برمجة التطبيقات (API) الرسمية ، يعطي تلميحات من هذا القبيل عن طريق رمز جانب الخادم (فئة / أسماء الملفات ، إلخ). مسلّحًا بهذا ، أنشأت كائنًا ذا مستوى أعلى كحاوية لنطاق المشكلة بالكامل ؛ ثم أضفت مساحات الأسماء في المكان المطلوب:

var App;
(function()
{
    App = new Domain( 'test' );

    function Domain( id )
    {
        this.id = id;
        this.echo = function echo( s )
        {
            alert( s );
        }
        return this;
    }
})();

// separate file
(function(Domain)
{
    Domain.Console = new Console();

    function Console()
    {
        this.Log = function Log( s )
        {
            console.log( s );
        }
        return this;
    }
})(App);

// implementation
App.Console.Log('foo');



I'm using this little thing. It gives you 'include' directive for both JS and HTML templates. It eleminates the mess completely.

https://github.com/gaperton/include.js/

$.include({
    html: "my_template.html" // include template from file...
})
.define( function( _ ){ // define module...
    _.exports = function widget( $this, a_data, a_events ){ // exporting function...
        _.html.renderTo( $this, a_data ); // which expands template inside of $this.

        $this.find( "#ok").click( a_events.on_click ); // throw event up to the caller...
        $this.find( "#refresh").click( function(){
            widget( $this, a_data, a_events ); // ...and update ourself. Yep, in that easy way.
        });
    }
});



Your question is one that plagued me late last year. The difference - handing the code off to new developers who had never heard of private and public methods. I had to build something simple.

The end result was a small (around 1KB) framework that translates object literals into jQuery. The syntax is visually easier to scan, and if your js grows really large you can write reusable queries to find things like selectors used, loaded files, dependent functions, etc.

Posting a small framework here is impractical, so I wrote a blog post with examples (My first. That was an adventure!). You're welcome to take a look.

For any others here with a few minutes to check it out, I'd greatly appreciate feedback!

FireFox recommended since it supports toSource() for the object query example.

في صحتك!

آدم




You don't mention what your server-side language is. Or, more pertinently, what framework you are using -- if any -- on the server-side.

IME, I organise things on the server-side and let it all shake out onto the web page. The framework is given the task of organising not only JS that every page has to load, but also JS fragments that work with generated markup. Such fragments you don't usually want emitted more than once - which is why they are abstracted into the framework for that code to look after that problem. :-)

For end-pages that have to emit their own JS, I usually find that there is a logical structure in the generated markup. Such localised JS can often be assembled at the start and/or end of such a structure.

Note that none of this absolves you from writing efficient JavaScript! :-)




Related