Backbone: 主干自定义构建

那会很好。

如果您对我如何模块化 Backbone.js 代码库感兴趣，请查看我的主干分支中的 customBuild 文件夹。 请记住，所有 Backbone 单元测试仍然成功通过。
https://github.com/gfranko/backbone/tree/modularBuilds

此外，以下是自定义构建 UI 如何工作的示例：
http://gregfranko.com/backbone/customBuild/

最后，这是我写的一篇博客文章，讨论可能只使用 Backbone 的某些部分：
http://gregfranko.com/blog/backbone-dot-js-convincing-the-boss-guide/

我真的很欣赏这个想法，尤其是 ruby​​ 依赖消失和 grunt 发挥作用的部分。

在某些情况下，我不需要 Backbone.Router（因为我没有路由但仍然喜欢使用 Backbone 来组织我的 JavaScript）。

另外，这与 LoDash（呃，希望没有人感到生气）自定义构建非常相配。

@asciidisco我还没有完成将自定义构建与 Grunt 集成的工作。 你知道你会如何处理吗？

@gfranko希望看到类似 jQuery 的实现（从 1.8 开始，他们也有自定义构建），
也许我分叉你的项目并在这个周末试一试，但我不完全确定我是否有足够的时间:(

@asciidisco别担心。 本周末我将查看 jQuery grunt 文件，看看他们是如何做的。

:+1: 用于模块化代码库

虽然多个文件通常很有用，但我认为 Backbone 不会从拆分源中受益。 该库相当小，因此自定义构建最多只能节省几千字节，而增加的复杂性将是显着的。

就其价值而言，这在之前的 #65 中至少讨论过一次。

例如，当用户使用带有 Backbone.js 的 jQuery Mobile 并且不想包含 Backbone Routes 时，用例又如何呢？

我同意默认的 Backbone 源应该保留为一个文件，但我建议将源分成多个文件（我意识到这需要更多的维护工作）也可以添加，以防用户不想要特定功能。

此外，我在我的博客文章中建议，允许用户不包含 Backbone 的所有功能将使 Backbone 在企业环境中更易于使用。

只是好奇，增加的复杂性是什么？

例如，当用户使用带有 Backbone.js 的 jQuery Mobile 并且不想包含 Backbone Routes 时，用例又如何呢？

只需从源中删除它。 它的标签相当清楚，而且很容易做到。

只是好奇，增加的复杂性是什么？

我指的是新的和现有的贡献者的复杂性。 为新项目编写代码总是令人生畏的，我们希望尽可能地鼓励它。 目前，Backbone 只需要一个可以提供本地文件的浏览器和一个文本编辑器。 需要一个构建系统/工具是一个很大的进步。

也就是说，我一般不反对自定义构建，我更喜欢您在博客文章中介绍的工具。 :)

你说得对，每个 Backbone 类对象都有明确的标签（这就是为什么我很容易拆分代码库）。 话虽如此，我认为大多数开发人员都不想接触他们正在使用的库的来源。

以 Require.js 和非 AMD 兼容脚本为例。 将 lib 包装在定义方法中很​​容易，但谁愿意这样做呢？

但是，是的，我确实听到了您所说的不要试图引入太多依赖项/复杂性。 猜猜我会把它作为一个单独的项目，并保持代码与主干源代码保持同步。

是的——我认为这是一个非常简洁的项目……但是 Backbone 受益于它是一个简单的单一脚本。 如果您安装了 Backbone，那么您已经拥有了它，并且您可以依赖它提供的所有可用功能。

Braddunbar：只需从源中删除它。 它的标签相当清楚，而且很容易做到。

Gah，这是一个陷阱！ 有一个官方的构建系统来确保质量、兼容性和功能会更好。

jashkenas：是的——我认为这是一个非常简洁的项目……但是 Backbone 受益于它是一个简单的单一脚本。

是的，我也挖掘了单个文件，这就是为什么 Lo-Dash 是单个文件但仍然支持自定义构建（尽管 jQuery 使它可以处理其存储库中的单个文件）。

自定义构建很棒，可以为开发人员提供更多控制权。 Lo-Dash 和 jQuery 支持自定义构建，唯一缺少的是 Backbone ;D

嘿，
如果你们中的任何人感兴趣，我制作了一个 grunt 插件来生成自定义的 Backbone 构建
“普通”主干源文件： https :

现在还没有真正测试过（虽然我运行的主干版本忽略了所有路由器和历史记录），它有效
好。 欢迎反馈。

@asciidisco谢谢你，你摇滚！

如果我们切换到 browserify 或 webpack 会很好，这样我们就可以轻松地两全其美（多个文件和单个文件）。

将Events作为单独的模块会很好。 在构建具有可选Model和Collection依赖项的自定义模块时非常有用。

我在我的 Angular 和 AngularJS 项目中使用 Backbone 模型和集合。 我只需要模型和系列，因为这个概念很棒。 我使用 is 作为数据访问层。 Angular 提供了 ui 层。

我最近写了一篇关于如何在 Angular 应用程序中使用 BackboneJS 的文章： https :

将 BackboneJS 分成几个组件真的很好，你可以只包含你需要的东西。

@jashkenas将 src 文件拆分为多个文件并让构建任务将它们合并为一个文件，这样您就可以同时拥有两个文件了：

• 一个简单的单个文件
• 并拆分源文件
  ?