ジモティーのフロントエンド事情

初めまして。

2020年末からジモティーでフロントエンドエンジニアとして開発している山口です。

今回はジモティーのフロントエンド事情について紹介します。

ジモティーフロントエンドの現状

現在のジモティーのフロントエンドはRailsのAction Viewを用いて

jQuery で Javascript 周り（一部のページの一部の DOM に対して jQuery 代替として Vueも利用）
Rails の decorator でフォーマットして Haml でマークアップ
Sass でスタイル付け

といった構成になっています。

しかしサービスの規模が大きくなってきたこともあり、どのidやclassをどの jQuery コードが参照しているのか追いづらかったり、似たスタイルを持つ似た名前のclassが乱立してしまいどれを利用すべきなのかの見通しがつかないなど、開発が辛くなってきているのが正直なところです。

Railsの開発チームはアプリ向けのAPIの作成やバックエンドの開発と並行してフロントエンド開発も行っているため、辛さが出てきた現状が会社として求める開発スピードUPの足枷になってきています。

新規プロジェクトにてReact(NextJS)を利用

今月リリースした新規プロジェクト、自治体向けの電子申請・申請承認システム「LOCONET（ロコネット）」にて、弊社としては初めて React を利用した開発体制を敷きました。

バックエンドはジモティーに引き続きReilsを利用し、フロントエンドはバックエンドとは完全に分離してReact(NextJS)+Typescript で作成、さらにOpenAPIによる APIドキュメント整備とStorybook によるコンポーネントのドキュメント整備を行うことでバックエンド開発者やデザイナーとのコミュニケーションを取りやすい環境を構築しました。

技術負債との比較

前述した現在のジモティーの開発状況と比べると今回の開発体制では

styled-compomentsを利用でスタイルのスコープを制限してスタイルの見通しが付きやすくなる
contextの利用を避けてあえてpropによるバケツリレーを選択することでstateなど変数の変更が追いやすくやる
Typescript によりコードがよりドキュメントとして理解しやすい形で残るようになったため、第三者がコードを追いやすくなる
バックエンドと分離されることでアプリチームと似た分担で開発が可能になり、適材適所の分担で開発が行えるようになる
デザイナーとパーツ単位で実装しているスタイルを見ながら密なコミュニケーションが取れるようになる

などのメリットを得ることができました。

代わりに

Typescript 導入により、追加で工数が発生してしまう
保守していかなかればならないものが増えた（OpenAPI,StoryBook）

といったデメリットは発生しています。

Typescript導入において型管理以外に特に時間を要したのは次に紹介する2項目です。

外部ライブラリ利用時の型調査の時間

外部ライブラリ使用した際にライブラリ内に定義されている型の内容、利用方法の確認に時間を要しました。

特に初めて利用するライブラリの場合、javascript時の倍は時間がかかる感覚です。

直で呼び出す場合より子コンポーネントへライブラリの一部を受け渡しする必要があった場合など子コンポーネントのpropの定義に悩むことが多かったです。（大抵公式のドキュメントにその場合の型の定義方法が書いてないので直接ライブラリを追ってみるしかなかったです）

例) React Hook Formの場合 https://react-hook-form.com/jp/get-started/

const { register, handleSubmit, watch, formState: { errors } } = useForm<Inputs>()

useFormで呼び出してきた各種メソッドregister, handleSubmit, watch, errors をコンポーネントへ受け渡したい時、どのような型で待ち受けるべきかがドキュメントからはわからず、なるべくanyなどを使わず実装しようとすると最適解を見つけるのに時間がかりました。

型推論のための追加記述

頻出するわけではないですが、遭遇した場合に解決の時間を用意したのがこちら。

適切な型推論が行われるようにするために javascriptだけならそのままで要件を満たして動作するコードに対して - typescriptが型推論に対応しているメソッドに書き直す - 自前で型推論させる処理を追加する（javascriptの動作上は必要のないコード）という対応をする必要が発生しました。

例)　filterを利用してarrayを整理しても方が絞り込まれない例

const x = [123, null] // 型推論結果 const x: (number | null)[]
const y = x.filter(v => v !== null)
console.log(y) // [123]
// 型推論結果 const y: (number | null)[]
// number[] にならない

このままではビルドが通らないので型ガードを駆使したりして型を絞り込む必要が出てきますがチームへのTSの知見が溜まっていないと解決まで時間がかかってしまいます。

...

しかしながら、 Typescript導入やOpenAPI、Storybookはある程度のコード規模が大きくなり、チームの人数が増えてきたときに効力を発揮する要素なので投資として受け入れるべきコストだと考えています。

VueとReactの違い

実は私はジモティージョイン前までVueをフロントエンド開発に利用していたため今回のプロジェクトが React に触れる初の機会でした。

そのため Vue 開発と比べた時の違いについてもいくつか感じることができましたので紹介します。

自由度が高く、良くするも悪くするも開発者次第なReact vs 形式がしっかりしており、とっつきやすいVue

Vue はコンポーネント内で何をどこに定義すべきかはっきりしているのに比べて、React はとにかく自由度が高いため、開発者がやりたいように柔軟な書き方ができる反面、選択肢が多いため、知見がない状態ではベストプラクティスを見出すのが難しいと感じました。

コンポーネントファイル内でstateやeventなどを定義する場所(Vueはdataやwatch,methodなど書き場所が固定されていて開発者でバラつかない）や、スタイルの定義方法は他のオープンソースの事例をいくつか参照してみましたがどれもバラバラで自分たちに合ったやり方を見出す必要がありました。

スタイル付けに関してはスコープをコンポーネント内に留めたいのと、なるべくcssそのままの形で記載ができることをとってstyped-componentをチョイスしましたが正直Vueの方がシンプルにcssそのまま埋め込め、sassなども導入しやすかったので扱いやすかった印象です。