何がしたい？

ERBやSlimを使用してフロントを構築しているRuby on RailsのWebアプリからフロントエンドをReact(またはNext.js等)に分離したい。

なぜ分離したい？

フロントとバックエンドの責務を分離した
バックエンドはAPIの開発に集中したい
フロントはAPIを取得してマークアップに集中したい
フロントとバックエンドのテストを分離したい
コンポーネント(部品)単位でフロント構築してレビューできるようにしたい
- Storybookの導入(これは別件)

現状整理

Ruby on Rails(MPA構成、Not API Mode)
フロントはERB(Slimでも多分同じこと)
動的な部分はjQuery(部分的にReactの実績あり)
ReactDOMは使わずにreact-railsを使っている
ビルドにはWebpack(Webpacker)を使っていた(今はShakapacker)
フロントのテストは存在しない(手動テスト or RspecのSystemテストでカバー)
Ruby on Rails側にはAPIが存在し、一部OpenAPIを導入
- まだOpenAPIの文化が定着していないが、書くように促している
スタイリングはRuby on Rails側で管理しているSCSSを使用
TypeScriptは導入済み

iwamasa

やることの優先順位

フロントエンドのディレクトリ構成、戦略を定義して共有する
→構造型(Atomic Design)やドメイン型(Feature)などのディレクトリ構成について意思決定する
新規ページ、新規部品についてはReact/TypeScriptを必須化する
→今後、ERBの使用は禁止して必ずReact Componentを使うようにし、移行を見据える
スタイリングはReactで完結させる
→Rails経由のSCSSは使用禁止とし、別途SCSSを管理するかTailwindCSSなどに移行する
フロントのテストを導入する
→Jestを導入して、フロントで完結したテストを実施できるようにする
Storybookを導入する
→Component単位で動作確認、認識合わせができるように導入する
react-rails/Shakapackerから分離
→Viteに移行するでもなんでも良いので、Railsから独立して動かせる状態にする(そのためには既存コードを順次移行する必要がある)
リポジトリの分離
→ここまできたらゴールは目前。完全にリポジトリも分けちゃう
デプロイの分離
→リポジトリ分けたからデプロイも一緒に分けようぜ

iwamasa

フロントエンドのディレクトリ構成

昔はAtomic Designが流行っていたけど、最近はFeatures型の構成が流行っているらしい。

名人さんの記事

この辺も良さそう

Blogサービスを例にディレクトリ構成を考えてみる

.
└── src
    ├── components  # 共通用
    │   └── Elements
    │       └── Button
    │           └── Button.tsx
    └── features # 機能ごと、ドメインごとに分ける
        ├── posts
        │   └── components
        │       └── Posts.tsx
        └── users
            └── components
                └── Users.tsx

ざっくりこんな感じ。ここからstoriesとか入れたり、API用の定義作ったりしていく。