2012-01-11 19 views
5

Estaba mirando los esquemas de Backbone-requireJS en GitHub, veo dos tipos diferentes de implementaciones.¿Hay una buena razón para envolver una función adicional invocada de forma inmediata alrededor de una definición de módulo requireJS?

https://github.com/david0178418/BackboneJS-AMD-Boilerplate/blob/master/src/js/views/viewStub.js tiene la siguiente como el viewStub:

function() { 
    "use strict"; 

    define([ 
      'jqueryLoader', 
      'underscore', 
      'backbone', 
     ], 
     function($, _, Backbone) { 

      return Backbone.View.extend({ 
       template : _.template(/*loaded template*/), 

       initialize : function() { 
        this.render(); 
       }, 

       render : function() { 
        $(this.el).append(this.template(/*model/collection*/)); 

        return this; 
       } 
      }); 
     } 
    ); 
})(); 

Mientras que la visión-talón de la otra plancha de caldera https://github.com/jcreamer898/RequireJS-Backbone-Starter/blob/master/js/views/view.js tiene la siguiente:

define([ 
     'jquery', 
     'backbone', 
     'underscore', 
     'models/model', 
     'text!templates/main.html'], 
function($, Backbone, _, model, template){ 
    var View = Backbone.View.extend({ 
     el: '#main', 
     initialize: function(){ 
      this.model = new model({ 
       message: 'Hello World' 
      }); 
      this.template = _.template(template, { model: this.model.toJSON() }); 
     }, 
     render: function(){ 
      $(this.el).append(this.template); 
     } 
    }); 

    return new View(); 
}); 

Mi pregunta aquí es: ¿Por qué es Existe una función de autoejecución alrededor de todo el módulo RequireJS en el primer ejemplo?

+0

@missingno gracias por la edición! – Karthik

Respuesta

1

No es necesario que haya un cierre de contención en este ejemplo. Crea un ámbito para que las variables o funciones declaradas no se filtren en el ámbito global. Pero cuando no está creando variables o funciones con nombre, entonces no hay nada que filtrar. Entonces no hay mucho punto.

La verdadera razón puede ser más simple de lo que piensas. Al igual que el uso de la señal de giro, incluso si no hay nadie cerca, adjuntar cada archivo de origen JS en una función autoejecutable es un buen hábito para entrar. Te salva de errores estúpidos. Entonces puede ser solo un ejemplo de un estilo de programación defensivo.

No hay ningún beneficio en este ejemplo, pero el costo de rendimiento relacionado en el tiempo de ejecución es totalmente insignificante. Entonces, ¿por qué no hacerlo de la manera "correcta" en caso de que aparezca algo nuevo y "mantenga" este módulo de alguna manera funky?

+0

Eso tiene sentido. ¡Gracias! – Karthik

+0

Eso tiene sentido. ¡Gracias! Tengo otra pregunta que olvidé agregar a la publicación original. En el segundo ejemplo, se devuelve una instancia del objeto View, es decir, 'new View()' desde el módulo. Si otros módulos hacen referencia a este módulo, ¿usarán la misma instancia de 'Ver', (O) van a ser instancias diferentes? Si es la misma instancia, me pregunto, ¿quién maneja esto? requireJS? – Karthik

+0

Eso es un poco de require.js. Creo que solo ejecuta el módulo requerido una vez y luego almacena el resultado en caché. Entonces sí, devolvería la misma instancia cada vez. Entonces 'return View;' podría tener más sentido. Si en su lugar devuelve el constructor, depende del código que requiera crear una instancia de una vista. –

0

No tiene sentido que lo haga, porque ya tiene una función que crea sus propios espacios de nombres.

Además, hay una desventaja: está obteniendo una sangría adicional, por lo que su código se vuelve menos legible.

Cuestiones relacionadas