Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
RailsからReactを剥がした話
Search
Riya Amemiya
December 03, 2023
Technology
780
0
Share
RailsからReactを剥がした話
Riya Amemiya
December 03, 2023
More Decks by Riya Amemiya
See All by Riya Amemiya
知ってた?JavaScriptの"正しさ"を検証するテストが5万以上もあること(Test262)
riyaamemiya
1
170
「え?!それ今ではHTMLだけでできるの!?」驚きの進化を遂げたモダンHTML
riyaamemiya
12
5.7k
そのJavaScript、V8が泣いてます。V8の気持ちを理解して書くパフォーマンス最適化
riyaamemiya
22
8.3k
「え?!それ今ではCSSだけでできるの!?」驚きの進化を遂げたモダンCSS
riyaamemiya
1
180
不健康エンジニア「健康」を知る
riyaamemiya
1
1.4k
AIと共同執筆してより質の高い記事を書こう
riyaamemiya
1
700
いつか使うかも貯金してたらめちゃめちゃ機能が増えてた話
riyaamemiya
0
940
TypeScriptの型で2進数計算
riyaamemiya
0
260
AIの力でテストのガバレッジ100%にした話
riyaamemiya
0
1.1k
Other Decks in Technology
See All in Technology
AI時代に、 データアナリストがデータエンジニアに異動して
jackojacko_
0
560
Agent Skillsで実現する記憶領域の運用とその後
yamadashy
2
1.6k
AIの揺らぎに“コシ”を与える階層化品質設計
ickx
0
270
そのSLO 99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs
vtryo
0
460
「背中を見て育て」からの卒業 〜専門技術としてのテスト設計を軸に、品質保証のバトンを繋ぐ〜 #genda_tech_talk
nihonbuson
PRO
1
800
鹿野さんに聞く!CSSの最新トレンド Ver.2026
tonkotsuboy_com
6
2.7k
SREの仕事は「壊さないこと」ではなくなった 〜自律化していくシステムに、責任と判断を与えるという価値〜 / 20260515 Naoki Shimada
shift_evolve
PRO
1
100
The 7 pitfalls of AI
ufried
0
200
"うちにはまだ早い"は本当? ─ 小さく始めるPlatform Engineering入門
harukasakihara
4
420
ボトムアップの改善の火を灯し続けろ!〜支援現場で学んだ、消えないための3つの打ち手〜 / 20260509 Kazuki Mori
shift_evolve
PRO
2
600
エージェント時代の UIとAPI、CLI戦略
coincheck_recruit
0
160
QAエンジニアはどうやって プロダクト議論の場に入れるのか?
moritamasami
2
410
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
199
73k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Documentation Writing (for coders)
carmenintech
77
5.3k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
360
30k
Making Projects Easy
brettharned
120
6.6k
A designer walks into a library…
pauljervisheath
211
24k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
420
Site-Speed That Sticks
csswizardry
13
1.2k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
brightonSEO & MeasureFest 2025 - Christian Goodrich - Winning strategies for Black Friday CRO & PPC
cargoodrich
3
690
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.4k
Transcript
RailsからReactを剥がした話 1
2
自己紹介 GMOメディア所属 西悠太 フロントエンドエンジニア X: Riya31377928 3
なぜ移行したのか ReactからRailsのERBに移行しました。 多くの方が「なぜ?」と思うかもしれません。 RailsからReactに移行するのはよくある話ですが、逆はあまり聞きません。 4
移行した理由は以下の通りです 移行したページはlpなのでReactのメリットがあまりない Reactのコードが負債になっている 自分以外にReactを書ける人がいない 5
移行したページはlpなのでReactのメリットがあまりない 移行したページはlpで、インタラクティブな要素はほとんどありません。 また、CSRを利用しているのでSEOにもあまりメリットがありません。 そのため、Reactを使うメリットがあまりないと考えました。 6
Reactのコードが負債になっている 外部の会社に委託して作成したため、Reactのコードが負債になっていました。 TypeScriptだけど型がない、コンポーネントが分割されていない、コードが複雑、などな ど。 7
自分以外にReactを書ける人がいない 私以外のチームメンバーはRailsをメインで書いているため、Reactを書ける人がいません。 たった数ページのためにReactを書ける人を育成するのは難しいと考えました。 以上の理由から、ReactからRailsのERB移行を決めました。 8
移行した手順 9
1. ロジックを整理する まず始めに、どんな工程を踏んで画面が表示されているのかを整理しました。 10
画面が表示されるまでの工程は以下の通りです 1. Railsのコントローラーでデータを取得する 2. RailsのコントローラーでReactのコンポーネントにデータを渡す 3. Reactのコンポーネントでデータを加工する 4. 必要に応じてReactからAPIを叩く 5.
Reactのコンポーネントでデータを表示する 11
特にネックになっていたのが、4の「必要に応じてReactからAPIを叩く」でした。 Railsのコントローラーでデータを取得しているのに、Reactから不足分のデータを取得してい ました。 そのため、何度も再レンダリングが発生していました。 12
2. コンポーネントを整理する 次に、移行対象のコンポーネントを整理しました。 コンポーネントAはBに依存していて、BはCに依存しているというような複雑な依存関係があ りました。 それらを整理し、移行対象のコンポーネントを特定しました。 13
3. コンポーネントを一個ずつ移行する コンポーネントを一個ずつ移行していきました 1. if文をRubyのコードに変換 2. 共通関数をヘルパーに移植 3. propsをlocal_assignsに変換 4.
コードを整理して可読性を上げる 5. JSを可能な限り削除する 14
苦労した点 15
見た目の互換性を完璧にReactと合わせないといけない lp作成部分がReactで作成されていたため、見た目の互換性を完璧に合わせるのは大変でし た。 React独自の機能をバニラJSで実装し直したり、CSSを修正したりしました。 ピクセル単位で見ると誤差はありますが、人間の目では全く分からないレベルになりまし た。 16
流れてくるデータが多次元配列 DBから取得したデータが多次元配列で流れていました。 [ ["id", 1], ["title", "Title"], ["description", "Description"], ["is_public",
true], ["page_url", "hoge"], ["name_param", "hoge"], ["school_id", 1], ["tpl_image", {"id"=>1, "image_url"=>"http://res.cloudinary.com/hoge, "image_smart_url"=>nil}], ... ] 17
本当はちゃんとしたデータ構造に直したかったのですが、他のページでも参照しているた め、今回は直さずに移行しました。 必要なデータには position というキーがあるので、それを使ってソートしました。 items.map { |item| item.deep_transform_keys(&:to_sym) }.each_with_index.sort_by
{ |item, index| [item[:position], index] }.map(&:first) # map で配列の中身をシンボルに変換 # each_with_index で配列の中身とインデックスを取得 # sort_by でposition でソートし、position が同じ場合はインデックスでソート # map でインデックスを削除 18
if文をRubyのコードに変換 私は普段からReactを書いているので、Rubyの真偽値の扱いに手間取りました。 JSでは、 '' や 0 などの値が false として扱われますが、Rubyでは ''
や 0 は true として扱われます。 19
ERBとReactの改行、空白の違い ERBでは改行や空白がそのまま出力されますが、Reactでは改行や空白が無視されます。 これになかなか気づけず、苦労しました。 20
ERB <p> <%= text %> </p> <p> こんにちは </p> 21
React const Hoge = () => { const text =
" こんにちは" return ( <p> {text} </p> ) } <p> こんにちは</p> 22
コードを整理して可読性を上げる React側でデータを加工していたため、コードが複雑になっていました。 そのため、コードを整理して可読性を上げるのに苦労しました。 Railsのコントローラーで整形してからデータを渡すように変更したり、必要なデータを一括 で取得するように変更したりしました。 バグ検証に時間がかかりましたが、コードが整理されていくのは楽しかったです。 23
JSを可能な限り削除する Reactで無駄にJSを書いていた部分があったので、可能な限り削除しました。 例えば、ホバー時にスタイルを変更するという処理は、 onmouseover と onmouseout を使 って実装しました。 24
まとめ そんなこんなで、ReactからRailsのERBに移行しました。 移行には苦労しましたが、コードが整理されていくのは楽しかったです。 React好きとしては、少し寂しい気持ちもありますが、移行してよかったと思っています。 適材適所で使うことが大切だと思います。 25
おまけ https://zenn.dev/gmomedia/articles/5a6819c5a9e9ad 26