【问题标题】:Pattern for Backbone app using requirejs使用 requirejs 的 Backbone 应用程序模式
【发布时间】:2012-07-08 16:11:02
【问题描述】:

我遇到了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 的情况下那样?还是想念我这里的东西?

【问题讨论】:

    标签: backbone.js requirejs


    【解决方案1】:

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

    优势:

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

    优势:

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

    缺点:

    你会得到很多样板导入。

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

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

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

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

    那么是哪一个?

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

    如果您打算几乎在任何地方(例如 jQuery、Backbone)都使用该库,那么只需将其保持在全局范围内即可。

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

    【讨论】:

    • 是否建议通过“扩展”当前模块来“伪造”导入整个包而不为所有内容添加前缀? (如jsfiddle.net/LuNxc)?这将限制对每个代码的修改量...
    • @phtrivier - 可能取决于你的情况 - 我从未真正尝试过。我可能会避免自己这样做,因为它增加了似乎不必要的复杂性。拥有一长串进口商品并不是世界末日,至少其他人很清楚发生了什么。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-08-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多