複数の開発環境またいで感じたTypeScriptとコンポーネント開発におけるよいところと改善点

この記事はTech KAYAC Advent Calendar 2021の13日目の記事になります。

こんにちは！技術部ひめのです。
最近はDARK SOULS IIIを今更ながらはじめ、死んではうなる日々を繰り返しています。

今年からTonamelというサービスのフロントエンドを担当しており、ひとつのプロダクトにフロントエンドに複数の開発環境がある状況での開発をやっています。そこで感じたTypeScriptとコンポーネント開発におけるよいところと改善点について、アドベントカレンダーというタイミングでまとめておこうと思います。

Tonamelとは

Tonamelはトーナメント開催プラットフォームです。大会の開催と進行をかんたんにするために、さまざまな大会形式や機能を提供しています。

2016年7月からサービスを開始し、今年で6年目を迎えたウェブアプリケーションです。

tonamel.com

技術スタックについて

そんなTonamelのフロントエンドでは、さまざまな機能開発をしながら、Nuxtへのリプレイスを2019年末ごろから段階的に進行しています。
そのため、開発環境が現状2つ存在し、リプレイスをしながら機能も開発している状況になります。

既存のフロントエンド開発環境

サービス開始時のスタックに関しては以下のようになっています。
一部のサーバーからのデータに関してはテンプレートファイル経由で取得しています。

TypeScript
Vue.js
- new Vue()での部分利用
Rollup
Stylus
jQuery
- DOM操作と$.ajaxによるAPI(GraphQL)通信
XSlate
- Perlのテンプレートエンジン

新フロントエンド開発環境

新しく移行中のフロントエンドのさわる技術スタックは以下のようになっています。
テンプレートファイルからのデータ取得はSEO関連以外は基本的にやめて、GraphQL経由のデータ通信に寄せています。

TypeScript
Nuxt.js
Webpack
Stylus
Pug (.vue ファイルの <template> 内)
Apollo Client
XSlate

開発体験について

上記のような2つの開発環境を行き来しながら開発していく上で、既存環境と新しい環境だとやはり新しい環境のほうが開発がしやすいと感じることが多かったです。

今回はコンポーネント開発での良い点をあげつつ、新しい環境において改善すべき点にもふれていこうと思います。

TypeScriptのよさについて

その前に、どちらでも採用されたTypeScriptはいいぞという話を書いておこうと思います。既存環境/新環境どちらでも利用しており、現在のフロントエンド開発では重要な要素だと感じでいます。

もうTypeScriptのよさはいろんなところで語り尽くされているのですが、ひとつだけいうと 「試行錯誤する回数が圧倒的に増える」ことによる生産性が向上すること だと考えています。
コードを書いているとかならずどこかで不正・意図しない挙動が発生するケース（ここでは簡潔に「失敗ケース」と呼称しておきます）があると思います。
この失敗ケースにいかにして早く気付けるかが実装においては重要で、はやければはやいほど生産性が高くなります。 TypeScriptを利用すると型のエラーによる失敗ケースに気づくことになります。
結果としてブラウザでの動作確認時に失敗ケースに気づくよりも手順的に気づくのがはやくなり、生産性が高くなることにつながるのではと考えています。

コンポーネント開発での良い点

TypeScriptのよさを軽く紹介したところで本題に入ろうと思います。

主に感じている良い点は2つあり、1つは「Single File Componentによる責務分離がわかりやすい」こと、もう1つは「コンポーネント単位でのユニットテストができる」ということです。

Single File Componentによるコンポーネントの責務と影響範囲がわかりやすい

旧環境ではスタイルとHTMLとJSが分離されており、ひとつのコンポーネントに関するファイルを3つ確認しつつ、そのファイルには他のコンポーネントのスタイルや実装が混在している状態となっています。
そのため、頭のメモリに置かれるデータ量が多い状況です。

新環境では、コンポーネントはVue.jsのSingle File Component(SFC)で記述する形に統一されており、ファイル内にHTML/CSS/JSがまとまった状態になっています。
結果として、コンポーネントの責務とファイル内の責務がほぼ一致することになり、影響範囲も「そのコンポーネントがインポートされている箇所」とシンプルになっています。
インポートされてる箇所以外での影響範囲を考えることが大幅になくなり、修正コストも低く感じています。

コンポーネント単位でのテストができる

既存の環境では.tsファイルのユニットテストが限度でしたが、新環境ではコンポーネント粒度でファイルが分離されていることと、テスト用のライブラリが提供されていることでコンポーネント単位でのテストが可能になりました。 Tonamelでは実際に記述できているコンポーネントは少数ですが、往々にして複雑になりがちな入力コンポーネントに対してのテストで利用したりしています。