Solo 前端团队：用纯 Ruby 构建 UI 系统

Source: Dev.to

“Partial”问题

我们热爱 Rails，热爱 ERB。但说实话：app/views 往往是任何 Rails 代码库中最乱的部分。

你从简单开始。然后抽取一个 partial。接着需要传递一个局部变量。

随后你需要加入逻辑：只有当用户是管理员时才显示页脚。

突然之间，你的 HTML 文件里充斥着 if/else 语句、Ruby 逻辑以及随意的变量。如果把 user 拼写成 use，Rails 不会在编译时报错，直到页面渲染时才崩溃。

多年来，业界一直告诉我们解决方案是 React。

“停止编写 ERB！构建 API，用 JavaScript 编写前端！”

但对于单独开发者或小团队来说，这是一笔巨大的开销。

于是 ViewComponent 出场。

什么是 ViewComponent？

由 GitHub 创建（如果你访问 GitHub.com，正在看的 UI 正是由它渲染的），ViewComponent 将 React 的 组件架构 引入 Ruby 世界。

不再是松散的模板文件，ViewComponent 是一个 Ruby 对象。

旧方式（Partial）

_user_badge.html.erb：

">
  

问题： 想要单独测试它几乎不可能。必须加载包含它的完整页面。

新方式（Component）

运行生成器：

rails g component UserBadge user

app/components/user_badge_component.rb：

class UserBadgeComponent ">
  

现在，在视图中，你可以像使用对象一样渲染它：

为什么这对单人开发者意义重大

1. 静默失败的终结

在上面的例子中，initialize 需要关键字参数 user:。
如果在渲染组件时没有传入 user，Ruby 会立即抛出错误。
它为你的 UI 强制了严格的接口，不再需要猜测 partial 需要哪些 locals。

2. 逻辑应放在 Ruby 而不是 HTML 中

注意 background_color 的逻辑已经移到了 Ruby 类里了吗？
这让模板文件保持整洁。你可以在标准的 Ruby 代码中编写复杂方法、使用 guard clause、处理边缘情况，而 HTML 只负责呈现 HTML 本身。

3. 隔离测试（超级能力）

通常，要在 Rails 中测试一个 UI 元素，你会写系统测试（Capybara）。它会启动浏览器、加载数据库、访问页面并进行交互，速度很慢。

使用 ViewComponent，你可以为 UI 编写 单元测试。

# spec/components/user_badge_component_spec.rb
require "rails_helper"

RSpec.describe UserBadgeComponent, type: :component do
  it "renders red for admins" do
    admin = User.new(role: :admin, name: "Boss")

    render_inline(described_class.new(user: admin))

    expect(page).to have_css ".bg-red-500"
    expect(page).to have_text "Boss"
  end
end

这些测试在毫秒级完成。你可以在不启动浏览器的情况下，测试 UI 的每一种边缘情况。

4. Lookbook / 预览

ViewComponent 让你可以使用 Lookbook 等工具。它为你的 Rails 应用创建一个“Storybook”。你可以在仪表盘中浏览所有按钮、模态框和卡片的画廊，切换它们的状态，实时查看效果。即使只有你一个人，也会有一种拥有专职前端团队管理设计系统的感觉。

总结

ViewComponent 是“Goldilocks”式的解决方案。

• 太冷： 混乱、不可测试的 ERB partial。
• 太热： 与后端分离的复杂 React/Next.js 前端。
• 恰到好处： ViewComponent。

它们为你提供了 React 的组织性和可测试性，同时保留了 Ruby on Rails 的速度与简洁。