Perché impostare una variabile app come "cattiva pratica" in angularJS?

Question

Ho guardato un certo numero di angularJS tutorial e guide di stile e hanno trovato commenti come questo (from Todd Motto)

Bad: 
var app = angular.module('app', []); 
app.controller(); 
app.factory(); 

Good: 
angular 
    .module('app', []) 
    .controller() 
    .factory(); 

ho imparato la tecnica del "Bad" con l'esempio e da allora hanno visto un paio di riferimento (diverso da questo) che dice che la tecnica "cattiva" è ... bene male.

Nessuno finora nelle mie ricerche dice PERCHÉ è cattivo?

Modifica:Perché questa domanda è diversa? Mentre le differenze sono sottili tra questa e la domanda duplicato proposto, ci sono due differenze importanti:

1. '? Qual è la migliore prassi' non è la stessa cosa di "Perché è male?" ... mentre la risposta accettata all'altra domanda si articola su "Perché", le due domande che hanno la stessa risposta non sono sufficienti essere marchiate in duplice copia.

2. Una ricerca vigorosa, utilizzando il testo esatto che ho inserito come titolo per questa domanda, non ha rivelato il duplicato proposto. Forse SE dovrebbe prendere in considerazione la possibilità di aggiungere "titoli opzionali" a una domanda per migliorare la ricerca ... ma quella caratteristica non è a posto e qualcun altro che fa la stessa domanda della mia non troverà ancora l'altra domanda.

Answer 1

variabili globali in generale tendono ad essere considerato cattiva pratica, anche se angular sé è una variabile globale e quindi penso che sia sinceramente non che grande di un affare fino a quando si sono coerenti.

problema può sorgere se si fa qualcosa di simile per sbaglio:

app = angular.module("app"); 
// some other file 
app = somethingNotAnAngularModule(); 

librerie esterne potrebbero sovrascrivere la variabile app, ecc ecc

Invece di usare il nome app, si potrebbe anche usare un nome che è specifico per la vostra applicazione ...

dustrModule = angular.module("dustr", []); 

---

concatenamento è una cosa, ma se si sta frazionamento componenti in file separati si può sempre ottenere il modulo con .module

// app.js 
angular.module("app", []); 

// LoginCtrl.js 
angular.module("app").controller("LoginCtrl", LoginCtrl); 

Answer 2

Il punto di non utilizzare var module = angular.module('foo', []); e quindi utilizzando la variabile è puramente supponente però. Niente di male nel farlo IMO soprattutto se si coppia che con browserify per esempio e il fare questo:

foo/FooModule.js:

var ng = require('angular'); 

module.exports = ng.module('Foo', []); 

foo/FooController.js:

var FooModule = require('foo/FooModule'); 

function FooController() { 
    this.bar = 'bar'; 
} 

FooModule.controller('FooController', FooController); 

module.exports = FooController; 

foo/FooRoutes.JS:

var Router = require('base/Router'); 
var FooController = require('foo/FooController'); 

function initialize() { 
    Router.route('/foo', 'FooController as foo'); 
} 

module.exports = initialize; 

main.js:

var FooRoutes = require('foo/FooRoutes'); 

FooRoutes(); 

---

bene, più importante di questo è che non si utilizzano funzioni anonime al momento di definire i controllori e fabbriche.

modo che ci si

function MyCtrl($dep1) { ... } 
function MyFactory() { ...} 

e poi

angular.module() 
    .controller('my', ['$dep1', MyCtrl]) 
    .factory('fac', MyFactory); 

questo modo di separare il codice effettivo da iniezione di dipendenza angolare e le dichiarazioni e mantenere tutti AngularJS roba in un unico luogo.

La ragione per cui alcune persone dicono che il primo approccio è negativo è perché si sta diffondendo la "roba angolare" dappertutto, dovendo scansionare l'intero codice per arrivare alle "cose" reali.

cercare di usare un espressione di una funzione immediatamente Invocato-(IIFE) per incapsulare tutto questo codice anche: [? AngularJS migliori pratiche per la dichiarazione del modulo]

(function(){ /* code */ }());