1

我遇到了这篇关于使用 requirejs 的骨干应用程序的文章。有一件事看起来很奇怪。每当他们需要在我的模块中引用 Backbone、Underscore 或 jquery 时，我必须要求它们：

define([
  'jQuery',
  'Underscore',
  'Backbone',
  'collections/projects',
], function($, _, Backbone, ProjectsCollection, projectsListTemplate){
  var projectListView = Backbone.View.extend({
    el: $("#container"),
...

那么真的有必要走这条路吗？是不是有点过度设计了？难道我不能在启动我的应用程序之前加载 Backbone 及其依赖项并将它们用作全局对象，就像在没有 requirejs 的情况下那样？还是想念我这里的东西？

4

1 回答 1

4

无论哪种方式都有优点/缺点。

优势：

您的依赖管理完全由 require.js 控制，而不是依赖于同步加载的全局范围的库。它优雅、模块化，可能是做事的正确方式。

优势：

交换库版本更容易，尤其是每个模块。老实说，我在实践中从未见过这种情况——这似乎是一种“假设”的情况，而不是实际的情况。如果你这样做了，那么你可能无论如何都在破解一些东西，牺牲了你首先将它们用作模块而获得的“代码优雅”。

坏处：

你会得到很多样板进口。

define(['jQuery', 'underscore', 'backbone', 'raphael', ...],

在大型应用程序中，可能需要六个库依赖项才能获得依赖项。在每个模块中。

对于 Backbone 繁重的应用程序来说，冗余感觉尤其不必要，其中每个模块都可能定义一个 Backbone 模型/控制器/视图 - 几乎每个模块都需要 Backbone。

Lib您可以将它们全部包装到您要引用的单个模块中，例如Lib.$(...)or Lib._(...)，但这只是将样板从导入中移出并放入代码中。它也否定了优势#2。

那么是哪一个？

我会说单独查看每个库并决定它应该是全局的还是它自己的导入模块。

如果您打算在几乎所有地方使用该库（例如 jQuery、Backbone），那么只需将其保持在全局范围内即可。

对于其他库，您可能只在几个视图中使用它们（例如 Raphael.js）。在这种情况下，将其作为模块导入。

于 2012-07-08T18:24:15.880 回答