requirejs - ejemplos - crear un evento jquery

¿Por qué usar los requirejs alternativos define: define(function(require){…}

Question

He visto a personas usar una "sintaxis" alternativa definida en require js que la descrita en la documentación de require js, o en muchos tutoriales.

Los habituales definen "sintaxis" :

define([''module/first''], function (firstModule) {
   //Module code with a dependency on module/first goes here.
});

Los alternativos definen "sintaxis" :

<script data-main="app/config" src="assets/js/libs/require.js"></script>

archivo: config.js:

require.config({
   paths: {
      jquery:      ''../assets/js/libs/jquery''
   }
});
require([''app'']);

archivo: app.js:

define(function(require) {
     var FirstModule = require(''modules/first'');
     //Module code with a dependency on module/first goes here.

¿Cuáles son las ventajas y desventajas de usar esta "sintaxis" alternativa?

Answer 1

Creo que su explicación es un poco engañosa: en ambos casos, tendrá una llamada de nivel superior con un atributo data-main especifica un archivo para iniciar el proceso de requerir diferentes módulos.

Así que típicamente tendrás esto en tu HTML:

<script data-main="app/config" src="assets/js/libs/require.js"></script>

Entonces, en ambos casos , tendría un archivo app/config que establece su configuración (aunque podría hacerlo directamente en el HTML) y, lo que es más importante, las llamadas require en sus módulos:

require.config({
  paths: {
    jquery:      ''../assets/js/libs/jquery''
  }
});
require([''app'']);

Ahora, cuando llegamos a la definición de módulos con dependencias, estos estilos difieren. En el estilo amd, usted pasa los nombres de los módulos (rutas) como una matriz, y una función que toma el mismo número de argumentos:

app.js

define([''module/first'', ''module/second'', ''module/third''], function (firstModule, secondModule, thirdModule) {
  // use firstModule, secondModule, thirdModule here
});

En la sintaxis de CommonJS simplificada, solo debe pasar require a define y luego necesita los módulos que necesite en línea:

app.js

define(function(require) {
  var firstModule = require(''modules/first'');
  var secondModule = require(''modules/second'');
  var thirdModule = require(''modules/third'');
  // use firstModule, secondModule, thirdModule here

}

Volviendo a su pregunta original, las ventajas del estilo CommonJS sobre el estilo amd deben ser claras.

Por un lado, con la sintaxis convencional, si se requieren muchos módulos, es muy fácil asignar módulos erróneamente a los nombres de variables incorrectos. Considere este caso común:

define([''jquery'', ''underscore'', ''backbone'', ''modules/first'', ''modules/second'', ''modules/third'', ''i18n'', ''someOtherModule''], function ($, _, Backbone, first, second, third, I18n, someOtherModule) {
  // ...
});

De inmediato, puede ver que cuando agregamos un nuevo módulo a esta lista, debemos tener mucho cuidado de que el nuevo argumento de función correspondiente aparezca en el lugar correcto, o bien podemos asignar jQuery a Backbone , etc. En algunos casos Esto puede crear errores muy sutiles que son difíciles de rastrear.

Ahora considere la sintaxis de CommonJS:

define(function(require) {
  var $ = require(''jquery'');
  var _ = require(''underscore'');
  var Backbone = require(''backbone'');
  var firstModule = require(''modules/first'');
  var secondModule = require(''modules/second'');
  var thirdModule = require(''modules/third'');
  var I18n = require(''i18n'');
  var someOtherModule = require(''someOtherModule'');
  // ...
}

Tenga en cuenta que:

1. El emparejamiento de módulo a nombre de variable es muy claro.
2. El orden de las declaraciones requeridas no es importante, ya que los nombres de las variables se emparejan por separado en lugar de como una asignación entre una matriz y una función.
3. Los módulos no necesitan ser asignados primero. Se pueden asignar en cualquier lugar, siempre que sea antes de que el módulo se utilice realmente.

Esas son solo algunas de las razones que me vienen a la mente, estoy seguro de que hay otras. Básicamente, si solo tienes una o dos dependencias, cualquiera de las dos sintaxis funcionará bien. Pero si tiene una red compleja de dependencias de módulos, la sintaxis de CommonJS es probablemente preferible.

Tenga en cuenta que en los documentos RequireJS, mencionan esta pequeña advertencia :

No todos los navegadores proporcionan resultados de Function.prototype.toString () utilizables. A partir de octubre de 2011, los navegadores PS3 y anteriores de Opera Mobile no lo hacen. Es más probable que esos navegadores necesiten una compilación optimizada de los módulos para las limitaciones de la red / dispositivo, así que solo haga una compilación con un optimizador que sepa cómo convertir estos archivos a la forma de matriz de dependencia normalizada, como el optimizador RequireJS.

Pero este no es un tema importante:

Debido a que la cantidad de exploradores que no admiten esta exploración de toString () es muy pequeña, es seguro utilizar estos formularios con todos los módulos, especialmente si desea alinear los nombres de dependencia con las variables que mantendrán sus valores de módulo.