Question

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

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

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

Answer 1

无论哪种方式都有利弊。

优势：

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

优势：

交换库的版本更容易，特别是每个模块。老实说，我从未在实践中看到过这种情况 - 这似乎是一种“假设”的情况而不是实际情况。如果你这样做的话，你可能无论如何都会在一起攻击某些东西，从而牺牲了你所获得的“代码优雅”，首先将它们用作模块。

缺点：

你获得了很多样板进口。

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

在一个大型应用中，它可能需要六个库依赖项才能到达您的依赖项。在每个模块中。

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

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

那么哪一个？

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

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

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

使用requirejs的Backbone应用程序模式

1 个答案: