模式的使用requirejs骨干应用 [英] Pattern for Backbone app using requirejs

问题描述

我遇到是约约与requirejs骨干应用这篇文章。有一件事似乎非常奇怪。每当他们需要骨干的参考，下划线或jQuery的在我的模块我不得不要求他们：

I came across this article about about backbone apps with requirejs. There is one thing that seems really odd. Whenever they need a reference of Backbone, Underscore or jquery in my module I have to require them:

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

那么，真的有必要走那条路？是不是有点过分设计？我不能只是加载骨干和它的依赖之前，我开始我的应用程序，并把它们作为全局对象就像我会做没有requirejs？这里还是我思念的东西？

So is there really a need to go that way? Isn't a bit over engineered? Couldn't I just load Backbone and its dependencies before I start my app and use them as global objects like I would do it without requirejs? Or miss I something here?

推荐答案

有优点/缺点两种方式。

There are pros/cons either way.

的优点：的

您依赖管理完全由require.js控制，而不是依靠同步加载在全球范围的图书馆。它的优雅，模块化的，并可能是正确的方式做事情。

Your dependency management is completely controlled by require.js, instead of relying on synchronously-loaded globally-scoped libraries. It's elegant, modular, and is probably The Right Way to do things.

的优点：的

它更容易在库的版本交换，尤其是每个模块。我说实话从来没有见过这在实践中 - 这似乎是一个假设情况，而不是实际的东西。如果你这样做，那么你很可能入侵的东西在一起，无论如何，牺牲code优雅您使用了他们作为首位获得模块

It's easier to swap in versions of libraries, particularly per-module. I've honestly never seen this in practice - it seems like a "what if" situation rather than something practical. If you do then you're probably hacking something together anyway, sacrificing the "code elegance" you're getting by using them as modules in the first place.

的缺点：的

您得到了很多样板进口的。

You get a lot of boilerplate imports.

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

在一个大的应用程序，它可以让你来的您的依赖关系之前采取半打库的依赖。在每个模块。

In a large app, it could take a half dozen library dependencies before you get to your dependencies. In every module.

冗余感觉为骨干为主的应用程序，其中每个模块可能定义一个骨干模型/控制器/视图尤其是不必要的 - 几乎的每个的模块需要骨干

The redundancy feels especially unnecessary for Backbone-heavy apps, where each module is probably defining a Backbone model/controller/view - almost every module requires Backbone.

您可以包装他们都成你喜欢引用库一个库模块。$（...）或库._（...），不过这只是移动样板出来的进口和到code。这也否定了优势＃2。

You could wrap them all into a single Lib module that you'd reference like Lib.$(...) or Lib._(...), but that's just moving the boilerplate out of the imports and into the code. It also negates advantage #2.

那么，哪一个？

我说为查看每一个单独的库并决定它是否应该是全球性的还是其自身的导入模块。

I'd say to look at each library individually and decide whether or not it should be global or its own imported module.

如果你要使用这个库的几乎无处不在的（例如jQuery的，骨干），那么就保持它的全球性的。

If you're going to use the library almost everywhere (e.g. jQuery, Backbone), then just keep it global.

有关您可能只在一对夫妇的意见使用它们其他库（例如Raphael.js）。在这种情况下，导入它作为一个模块。

For other libraries you might only use them in a couple views (e.g. Raphael.js). In that case, import it as a module.

这篇关于模式的使用requirejs骨干应用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！