複数のNuxt.jsを用いたプロジェクトに携わってきて感じたこと #JavaScript

みなさんこんにちは@y_temp4です。

自分は現在フリーランスのエンジニアとして主にフロントエンドの開発を行っており、これまでに複数の Vue/Nuxt の案件に携わってきました。

というわけで今回は、いくつかの Nuxt プロジェクトに関わってきて得た知見についてシェアしていければなと思います！

想定読者

この記事は以下のような方を想定読者として書いています。

Nuxt を導入すべきか迷っている/新規プロジェクトで Nuxt の利用を検討している
Nuxt の構成で迷っている
Nuxt の利用について興味がある

Nuxt でプロジェクトを初める条件

まずはじめに Nuxt のプロジェクトを初める条件ですが、基本的に Nuxt はフロントエンドのフレームワークであり、バックエンドと疎結合な作りになっていることが望ましいです。いわゆる SPA を作る感じですね。

ですので、新規にプロジェクトを立ち上げる際は、バックエンドは完全に API サーバーとしてフロントエンドと分離させるような設計にすべきでしょう。

例えば、自分が初めて Nuxt のコードを書いた際はバックエンド API が AWS の Lambda + API Gateway でした。

参考：【ALIS のシステム】サーバサイドアーキテクチャ：その１〜ALIS サーバサイド構成〜 | ALIS

余談：なぜ SPA で開発するのか

本記事のメインの話題とは話が逸れるので詳しくは書きませんが、SPA で開発する必要性・メリデメに関しては、以下のスライドが参考になるかと思います。

私たちはなぜ SPA で開発するのか / Why you choose SPA - Speaker Deck

Nuxt プロジェクトの構成で意識すべきこと

Nuxt のプロジェクトをいくつか見てきた感想として、自分が一番思うのは「Nuxt の仕組みに沿った形で作ったほうが良い」ということです。まぁフレームワークを使う上で、フレームワークの仕組みに乗っかったほうがいいのは当然かも知れませんが、フロントエンドの構成はよりバックエンドよりもおざなりになりがちかなと感じています。

例えば Nuxt にはモジュールという概念があり、これを用いることによってある程度品質の担保された機能を実装できます。

また、Nuxt のプロジェクトに元から用意されたディレクトリ構造くらいは守るようにしましょう。

Nuxt は変化の速度が早いフレームワークであるので、独自に実装した箇所がバージョンアップの追従の足枷になるケースがよくあります。ですので、Nuxt の機能を逸脱したことをやろうとする場合、それにそこまでする価値があるか・既存の仕組みで実現できないか、よく検討した方が良いと感じています。

TypeScript の導入

Nuxt における TypeScript の導入は、基本的に以下の公式ドキュメントに沿えば OK です。

Nuxt TypeScript

しかし、それ以外の細かい点で TypeScript 導入を行う際につまずいたポイント等があるので、今回はそれについて列記します。

Nuxt をプログラムで使う際の設定

「Nuxt.js をプログラムで使う」にあるように、通常のnuxt-tsコマンドではなく Express などから Nuxt を動かしているケースでは、@nuxt/typescript-buildの関係でうまく動作しないことがありました。

おそらくすぐに改善されるかとは思いますが、この記事の執筆時点での解決方法を記述しておきます。

import tsModule from '@nuxt/typescript-build'

...

  if (config.dev) {
    await nuxt.moduleContainer.addModule(tsModule)
    const builder = new Builder(nuxt)
    await builder.build()
  } else {
    await nuxt.ready()
  }
...

メインの部分以外はよくあるコードと同じなので省略します。このコードはtypescript-build/test/module.test.tsを参考に書きました。

Lint について

見落としがちですが、Nuxt での eslint の設定は@nuxtjs/eslint-config、もしくは TS を使う際は@nuxtjs/eslint-config-typescriptを使うと、.eslintrcをスッキリとした形で記述できます。

.eslintrc.js

module.exports = {
  extends: ['@nuxtjs/eslint-config-typescript']
}

ただ、2019 年 11 月に TypeScript の 3.7 が出ましたが、このパッケージのアップデートは TS3.7 への対応が少し遅く、ちょっとだけやきもきしたのを覚えています。

今後 TS 等の追従に伴い@nuxtjs/eslint-config-typescriptのアップデートが待てない方は、中の実装まで一応確認しておいたほうがいいかもしれません。

さいごに

Nuxt のプロジェクトに関わってきて思ったのは、やはり Nuxt は比較的簡単にはじめられる反面、フロントエンドのよくある規則等を把握しておかないとすぐに破綻するリスクもある、ということです。

今後、Vue に関しては Vue のバージョン 3 にてComposition APIが導入されこれが使われるようになると、おそらくより設計力が求められるようになるのではないか、と感じています。

Nuxt のプロジェクトでも Composition API を考慮した実装が追加されていくでしょうから、この辺は意識しておく必要があります。

個人的に Composition API は今ある Vue の問題（主に型周り）を解決しうる素晴らしい仕組みかと思いますが、規約等をきちんと決めて開発を始めないと既存のコードよりも実装のつらみが出てくることが予想されます。

参考：Vue Composition API のコラムっぽいもの集 - mya-ake com

繰り返しになりますが、今後 Nuxt の開発をする方はこの辺の流れの変化にも対応できるように意識しつつ開発を進めていくことをオススメします！

さいごに、この記事が参考になった方はぜひいいねしていただけますと幸いです！

最後まで読んでいただき、ありがとうございました 😄