9

我希望使用gem react-rails将 ReactJS 实现为我的 Rails 应用程序的视图。到目前为止，我只使用该标准.erb在我的 RoR 应用程序中呈现我的视图，并且我想知道一些关于如何使用 React 来实现它的问题。

例如，当您想为 RoR 中的模型创建表单时，您“只是”使用以下命令创建表单：

<%= form_for(@product) do |f| %>
  <%= f.text_field :name %>
  ...
  <%= f.submit %>
<% end %>

这会自动使用正确的路由，生成 CSRF 令牌，使用正确的 CSS id&class等等......

现在，如果我使用 React，我必须处理所有这些吗？并在 JSX 中以老式的方式在渲染中创建表单？

# My view .html.erb
<%= react_component 'Form', {} %>

# My js.jsx file
var Form = React.createClass({
render: function () {
  return (
    <form className="new_my_model" onSubmit={this.handleSubmit}>
      <input style={inputStyle} type="text" className="my_model_name" />
      ...
      <input type="submit" value="Post" />
    </form>
  );
}
});

没有像 Ruby for React 这样的“自动生成功能”吗？

我在网上找到了一些关于 React & Rails ( 1 , 2 , 3 ) 教程的资源，但大多数时候他们说的是不同的东西。一些使用 JSX，一些咖啡，而官方 React 网站推荐使用 JSX。有人用refs，有人用，states一切都是这样！

是否有一个很棒的教程可以用作使用 React 构建我的应用程序基础的参考？

4

1 回答 1

27

简短的回答是，您在 JSX 中编写 React 组件，与在传统视图中编写的 DOM 元素分开。React 需要完全控制它能够正常工作的 DOM 元素，否则你将一直与它作斗争（尽管有限的使用可能会成功，但它可能很脆弱）。

冒着我没有真正回答您要学习的内容的风险，这里有一些想法可能会有所帮助：

  • 首先，要意识到 ReactJS 还很年轻，与 Rails 的集成甚至更年轻：最佳实践仍在被发现和决定中，因此选择一种方法并使其成功与选择一些最佳方法一样重要。
  • 其次，关注点没有很好分离的混合技术通常难以以易于扩展的方式保持组织和管理。ReactJS 是一种视图技术，因此如果您尝试以无组织的方式混合方法，分离您的视图机制可能会变得困难，特别是因为 ReactJS 如何处理 DOM 管理。此外，您正在处理两个不同生态系统的交集，因此支持更薄。

  • 您可能有三种主要方法：

    • 最小的 JS（以 JS 增强视图的经典方式使用 RoR，
    • 以最少的 RoR 视图构造将大部分视图移动到 ReactJS，以及
    • 单独的服务层（使用 RoR 为 AJAX 提供 API 与单独的 Web 服务一起使用，该 Web 服务呈现用 ReactJS 编写的 UI（因此不将 ReactJS 直接集成到 Rails 中）

  • 毫无疑问，这些主题有很多变化，但这些可能是主要的。

我只开发了几个可以做到这一点的应用程序，所以请对我的评论持保留态度。不过，对于新应用程序，我倾向于使用单独的服务层方法，因为工具要容易得多。我倾向于只在现有应用程序中使用 ReactJS，如果我的视图中有一个特别重 JS 的部分并且该功能有很好的界限。

最小的 ReactJS

在经典的 Rails 视图中，我们倾向于使用 JS 来增加客户端行为的视图：大部分视图计算是在服务器端完成的，然后我们让 JS 为某些目标目的操作 DOM 的各个方面。这对 React 来说可能很困难，因为 React 负责 DOM 的元素以保持状态更新。但是你仍然可以将 ReactJS 用于页面元素，就像你可以在 Rails 中渲染部分视图一样，只要“部分”是有界的。

使用 React-Rails gem，只需让您的视图渲染一个 React 组件，就好像您要使用部分组件一样，然后让该组件直接处理其组成元素，如果您在客户端使用期间需要来自服务器的更多内容，则使用 AJAX 调用。这会在您的视图中创建一个有限的、集中的关注点分离，您可以使用传统的 JS 技术来收集围绕您的组件的其他页面 DOM 信息（尽管如果您做的事情超出了非常有限的形式，这可能会变得困难和混乱 - - 如果你做了很多事情，可能应该重新考虑）。

这种方法的主要优点是您可以开始将 ReactJS 引入现有应用程序，并在您发现它有用时开始迁移功能。对于某些客户端密集的事情，比如说一些具有大量客户端交互的表单字段，但它们是有界的，这种技术可能是一个很好的候选者。

Rails 中的 ReactJS 视图

在这种方法中，我们可以使用 Rails 来渲染视图布局（即 HTML 包装器，但没有内容），然后让特定的视图要么是 ReactJS-only，要么是更传统的 ERB/H​​aml/Slim 视图。在这种方法中，Rails 视图将为页面建立一个主要的 React 组件，然后在 ReactJS 中完成其余的工作，以在它自己的 JSX 中管理该部分（通常是整个内容窗格）。这样，您的 JSX 仍然由您的资产管道提供服务，但实际上您已经从 React 处理了页面的核心表示，并且仅将 Rails 用于最小的布局目的，并允许某些视图基于 ReactJS其他的基于 Rails。

正如我所描述的，我宁愿假设一个多页应用程序。如果您正在编写单页应用程序，那么这种技术可能只是以一种简单的方式使用 Rails 进行演示。

尽管如此，还是有一些优点：

  • 同样，您可以混合和匹配不同页面的技术，作为将 ReactJS 逐步引入应用程序的一种方式；比如说，作为一种转换某些视图直到所有视图都基于 React 的方法。然后，如果您愿意，更容易转向分离服务层方法。
  • 你仍然可以在第一次渲染时使用视图从控制器向 ReactJS 组件提供一些信息，因为你的视图仍然会启动 React 组件。对于 React 处理其子组件后的任何其他信息，您仍然需要使用 AJAX（与任何其他 JS 功能没有任何不同）。
  • 正如您所指出的，Rails 仍在帮助您解决 CSRF 和那些应用程序范围的问题。

单独的服务层

这种方法完全将视图与后端服务分开。将您的 Rails 应用程序编写为完全呈现 JSON 的 API 服务器。所有核心逻辑仍然在控制器和模型中处理，因此设计的一部分基本上是完整的。事实上，你不需要经典的 Rails。其他框架，如 Grape 或 rails-api gem 可能更合适，因为它们重量更轻，因为您不会渲染任何视图或需要这些帮助程序。

然后你编写一个单独的基于 ReactJS 的应用程序（记住 ReactJS 也可以是服务器端的），它只专注于演示，只使用你的 RoR API 服务来获取和发布信息。

这种方法的注意事项：

  • 你会得到一个非常清晰的关注点分离：你的 Rails（或其他）应用程序专注于作为服务的数据/逻辑层，而你的 ReactJS 应用程序专注于呈现。以这种方式更多地使用 Rails 是一种趋势，您可以获得另一种水平扩展应用程序的方法。
  • 工具更容易，因为两者都更同质（单独的自动化测试更容易）。有一个围绕 RoR 的生态系统以及一个围绕 JS 和 ReactJS 应用程序的生态系统，但是这些生态系统的交集要少得多，因此您会发现自己在其他两种技术中更多地与工具作斗争。使用单独的层，这不是问题。
  • 适用于新应用程序，但可能更难转换现有应用程序（您必须同时转换控制器和视图）。

祝你好运！

更新（2015 年 9 月 2 日） 您可能会发现这篇博文很有启发性： http ://www.open mindinnovations.com/blogs/3-ways-to-integrate-ruby-on-rails-react-flux by Blaine Hatab（3 /2015）。这篇文章概述了三种方法，它们与我上面提供的高级概述有些相似，但旨在更全面地了解如何进行。他们列出的三种方法是

  • 方法 1：在 Rails 内部使用 React 和 react-rails
  • 方法 2：Rails 中的 React/Flux 前端应用程序
  • 方法三：分离 Rails API 和 React/Flux 前端应用

您可能会发现此描述更有用，并且他提供了参考以查看更多详细信息。

于 2015-07-25T19:16:29.443 回答