javascript - 需要模式 Browserify/Angular

Question

我正在一个使用 angular 和 browserify 的项目中工作，这是我第一次同时使用这两个工具，所以我想要一些关于 require 的方法的建议带有browserify的文件。

我们可能会以不同的方式导入这些文件，直到现在我都尝试过这种方式:

Angular 应用程序:

app
  _follow
     - followController.js
     - followDirective.js
     - followService.js
     - require.js
- app.js

对于插件文件中的每个文件夹，我创建了一个 require.js文件，在其中我需要该文件夹的所有文件。像这样:

var mnm = require('angular').module('mnm');

mnm.factory('FollowService', ['Restangular',require('./followService')]);
mnm.controller('FollowController',['$scope','FollowService',require('./followController')])
mnm.directive('mnmFollowers', ['FollowService',require('./followDirective')]);

然后要求所有 require.js名为 app.js 的唯一文件中的文件这将生成 bundle.js
问题:

这种要求文件的方式可以是一个很好的结构，或者当我需要测试时会出现一些问题？我想看看你用 angular 和 browserify 实现良好结构的方法

Answer 1

遗憾的是，AngularJS 和 browserify 并不是很好的匹配。当然不像 React 和 browserify，但我离题了。

对我有用的是将每个文件作为 AngularJS 模块(因为每个文件已经是 CommonJS 模块)并让文件导出它们的 AngularJS 模块名称。

所以你的例子看起来像这样:

app/
  app.js
  follow/
    controllers.js
    directives.js
    services.js
    index.js

app.js看起来像这样:

var angular = require('angular');
var app = angular.module('mnm', [
  require('./follow')
]);
// more code here
angular.bootstrap(document.body, ['mnm']);

follow/index.js看起来像这样:

var angular = require('angular');
var app = angular.module('mnm.follow', [
  require('./controllers'),
  require('./directives'),
  require('./services')
]);
module.exports = app.name;

follow/controllers.js看起来像这样:

var angular = require('angular');
var app = angular.module('mnm.follow.controllers', [
  require('./services'), // internal dependency
  'ui.router' // external dependency from earlier require or <script/>
  // more dependencies ...
]);
app.controller('FollowController', ['$scope', 'FollowService', function ...]);
// more code here
module.exports = app.name;

等等。

这种方法的优点是您可以尽可能明确地保持依赖关系(即在实际需要它们的 CommonJS 模块中)，并且 CommonJS 模块路径和 AngularJS 模块名称之间的一对一映射可以防止令人讨厌的意外。

您的方法最明显的问题是您将要注入(inject)的实际依赖项与期望它们的函数分开，因此如果函数的依赖项发生变化，您必须接触两个文件而不是一个。这是一种代码味道(即坏事)。

对于可测试性，任何一种方法都应该起作用，因为 Angular 的模块系统本质上是一个巨大的 blob，并且导入两个定义相同名称的模块将相互覆盖。

编辑(两年后):其他一些人(在这里和其他地方)提出了替代方法，所以我可能应该解决它们以及权衡是什么:

为您的整个应用程序拥有一个全局 AngularJS 模块，并且只需要对副作用进行需求(即，除了操作全局 Angular 对象外，不让子模块导出任何内容)。

这似乎是最常见的解决方案，但完全没有模块。然而，这似乎是最实用的方法，如果您使用的是 AngularJS，那么您已经污染了全局变量，所以我想拥有纯粹基于副作用的模块是您的架构问题中最少的。

在将 AngularJS 应用程序代码传递给 Browserify 之前连接它。

这是“让我们结合 AngularJS 和 Browserify”的最直接的解决方案。如果您从 AngularJS 的传统“只是盲目地连接您的应用程序文件”位置开始并且想要为第三方库添加 Browserify，那么这是一种有效的方法，所以我想这使它有效。

不过，就您的应用程序结构而言，添加 Browserify 并没有真正改善任何东西。

与 1 类似，但每个 index.js 都定义了自己的 AngularJS 子模块。

这是 Brian Ogden 建议的样板方法。这具有 1 的所有缺点，但在 AngularJS 中创建了一些层次结构，因为至少您有多个 AngularJS 模块，并且 AngularJS 模块名称实际上对应于您的目录结构。

然而，主要缺点是您现在需要担心两组命名空间(您的实际模块和您的 AngularJS 模块)，但没有强制它们之间的一致性。您不仅要记住导入正确的模块(这又完全依赖于副作用)，而且您还必须记住将它们添加到所有正确的列表中，并将相同的样板添加到每个新文件中。这使得重构非常笨拙，并且在我看来是最糟糕的选择。

如果我必须选择今天，我会选择 2，因为它放弃了 AngularJS 和 Browserify 能够统一的所有伪装，让两者各司其职。另外，如果你已经有一个 AngularJS 构建系统，它实际上只是意味着为 Browserify 添加一个额外的步骤。

如果您没有继承 AngularJS 代码库并且想知道哪种方法最适合开始一个新项目:不要在 AngularJS 中开始一个新项目。要么选择支持开箱即用的真正模块系统的 Angular2，要么切换到不受此问题困扰的 React 或 Ember。