3

我正在开发一个标准的 Rails 应用程序，到目前为止我还没有使用任何 AJAX，只是很好的 HTML。我的计划是迭代地添加“远程”链接和所有类似的东西并支持 JS 响应，因为我知道生成 JS 服务器端是非常非常邪恶的，但我发现它也非常方便，简单、快速和它使应用程序足够灵活，并且 i18n 开箱即用。

使用纯 JSON 方法会更轻松，但需要大量客户端编码。

现在想象一下，在这个应用程序中，用户有一个邮箱，因为他们的想法是他们可以在不重新加载页面的情况下执行大部分甚至所有操作，所以邮箱计数器永远不会改变，除非他们手动刷新页面。

所以，问题来了：处理这个问题的最佳方法是什么？

  1. 我考虑过使用 Ember（用于数据绑定），并通过某种用于 ruby​​ 的把手实现与 rails 共享视图。那将是非常棒的，但对开发人员（我）来说不是很透明。虽然我想我只需要编写 ember 将使用的车把视图，其余的仍然可以按照它们的原始格式编写，不是吗？

  2. 另一种选择可能是使用某种事件系统（可能是 EventSource？），并使用方便的 JS 视图方法，并监听这些事件。我猜这些应该是 JSON 对象，并且客户端必须经过编码才能处理它们。这似乎有点麻烦，我需要一个针对 heroku（faye？）的解决方案，这是我的应用程序所在的位置。有什么提示吗？

我认为 ember 方法是更强大的方法，但似乎也相当复杂，我不想重复自己的服务器和客户端。

编辑：

我见过这个，这或多或少是选项#2。

4

1 回答 1

0

使用 JavaScript 框架的优点之一是整个应用程序可以连接并压缩到一个 JavaScript 文件中。假设现代浏览器积极缓存 JavaScript，浏览器将不再需要在初始页面加载后请求这些资产。

使用 JavaScript 框架的另一个优点是它要求您成为自己 API 的使用者。如果移动应用程序或第 3 方有可能访问它，那么充实应用程序的 API 供您自己使用可能会减少未来的工作量。

如果您不需要您的应用程序使用等效的 HTML 响应来响应每个请求，我认为可以为使用 JavaScript 框架做出令人信服的案例。

如果您的应用程序需要使用等效的 HTML 模板响应每个请求，则可能会失去其中的许多好处。Ember 核心一直相对直言不讳，反对支持这种渐进式增强风格。考虑到以这种方式使用 JavaScript 框架的工具相对不稳定且不成熟，我可能倾向于使用选项 2 来完成此操作。

于 2013-10-31T02:59:50.760 回答