sena-v.com

sena-v.com
画像

画像

画像
scroll top

Nuxt + TypeScriptの現場開発感

Nuxt + TypeScriptの現場開発感

Nuxt

Nuxt + TypeScriptの環境でフロント~バックエンドまでトータル開発をしたのでその時の所感。

良かった所

コンポーネント単位の開発に順応しやすい(Nuxt)

1コンポーネント内にHtml・JavaScript・Css(Sass)が纏められているため、他に派生しないような機能ごとの開発であれば全体を理解しやすくプロジェクトに入りやすいと思う。バックエンド開発者でJSについて理解が薄めでも基本的にはライフサイクルフックとmethodsだけ理解してもらえばデータ処理はバックエンドに任せ、取得したいタイミングのライフサイクルフックでAPIを叩いてあげればあまり難しいことは考えなくてもいい。

多少のコンポーネント数であれば、JavaScript部でコンポーネントを取り込んでhtmlにパーツとして配置するだけで良いので基本的にはJSのimoport部を見て判断するだけでいい。上記のJSの記述と合わせると基本的にはJS部分を見るだけでどれくらいの役割を持っているか判別できるため簡単。

ルーティングがわかりやすい(Nuxt)

pagesへの配置がurlルーティングと一致しているためマイクロ構成のサービスであればかなり開発が楽だった。基本的にはpages以下フォルダを使って開発していけばいいため、ディレクトリが散らかることなくコンパクトに作業することができた。ルーティングについてはNextの方も同じような方式をとっているためNuxtの強みではないけど、Nuxtを使うということのメリットではあるので多ページになるようなサイト構築する場合は素のVueではなく最初からNuxtを使う一度だと思う(素のvueはどの層のメリットになるんだろう……学習層とか後入れ?)


悪かった所

共有コンポーネントが多くなればなるほど複雑になる(Nuxt)

コンポーネントの導入については規約でケバブケースとなっているため、html部のコンポーネントを探すのが少し面倒だった。ここに加えてコンポーネントが複雑になるとAからB、BからCへのprops渡しを考える必要があり、データ管理が非常にわかりにくくなる。

ある程度時間が取れるようなPJではない場合、Node主体ではないNuxt開発だとどこでエラーが出てるのかの切り分けが滅茶苦茶面倒になるため、よりシンプルな設計であることが求められて地味に難易度が上がるのかなと思う。拡張性を考えるならコンポーネント内での副作用は避けたいけど、分割すればするほどNuxtというか.vueファイルの良さが失われるような……。分割数が増えれば増えるほど個人的にはJS/TSを使い一元管理してシームレスに扱えるNuxt(React)のが便利かなーと思った。

グローバルthisにAnyが入ると更に面倒になる(TypeScript)

これは参加したPJの設定感のせいかもしれないが、型を設定していてもグローバルに新規変数を設定することができ、その変数には型がなかったせいでAny型を対応する羽目になった事があった。オブジェクトについても型指定が厳密にできていないとAny許容されてしまっている箇所が多かったりで開発時にエラー切り分けが面倒だったことがあった。その際見直してみた所JS部での片付がされていなくてもビルドが通ってしまっているモジュールがいくつか見られたため、TypeScriptは導入されているけどテンプレートレベルでの使用が任意になっている感じだったのでそりゃ駄目だろっていう……

型導入するなら当たり前だと思うけど全体で使わないと意味がなくなっちゃうのでルール化・徹底は必須だよね。途中から入ったPJでこんなことがあったらきちんと声を上げるか影響がない範囲であれば諦めましょう。そのチケットが飛んできたら泣きましょう。

単純に超デカい行数になるため読み辛くなる(Nuxt)

単純に.vueファイルが読み辛い。1ファイルにまとめようとするとRegisterページなんて1万行超えたりすることはザラだし、かといって分割するとモジュール内モジュール内モジュールになって複雑性が増したりでどっちを取るか問題になってくる。加えて上記型問題のようにTSが入っている前提で開発していたら子モジュールに型定義が入っていなかったりすることを考えると……(実際あってめちゃ辛かったので)

Nuxtはコンポーネントについては結構切り分けてったほうが開発しやすい印象だけど、JS部が長くなればなるほど切り分けるというよりはユニークな処理になってくるのでバックエンド側でほぼ完結させて、フロントは表示するのみくらいの規模感に向いているような印象だった。JavaでSpring使って業務アプリ開発するよりは開発体験がいいし、環境構築とかビルドの面から見てもやりやすさはあったのでそういう意味ではマシだったのかなと。自分がいた所は結構肥大化したPJになってたから大変だったのもあるのかもしれない。

所感

書き出してみたけど……Nuxtというよりは設計・ルール決めが甘いのが問題では?という感覚になった。 NuxtについてはNext等React系列よりもやはり1ファイルで完結するという触れ込みがありレガシー環境からの脱却プロジェクトで一番最初に選択されると思う。手軽に導入できるけどコンポーネントが複雑になるにつれて設計・ルールの甘さがゴリゴリに効いてくるため、内部にある程度わかっている人が多そうなReact系の方が大きめのプロジェクトになっても破綻はしづらいのかなと思う。

TypeScriptを実務で使った初めての現場ではあったけどやっぱり型があると切り分けが早くなって、ビルド前にミスに気付けて開発体験的にはめちゃくちゃいい。NodeJSの開発速度が個人的には好きだけど、型を導入して少し定義に時間がかかってもそれを取り返すメリットが有るからTSについては全く文句がなかった。TypeScriptはいいぞ

Author: sena-v       © 2021, Built with Gatsby