Vue + TypeScript で 0 → 1サービス開発

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 ● Twitter: @chiba_rry ● GitHub: ryamakuchi ● BASE Frontend Engineer 自己紹介最近バ美肉しました。アバターは「薄荷ちゃん」です！ BASE には2021年に入社してカート開発（React）や TikTok 商品連携・広告 App の開発（Vue）を行ってきました。最近はフロントエンドだけでなくてバックエンド（PHP）も書いてます。

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

5 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 Vue + TypeScript Vue と TypeScript の「相性問題」は Composition API や Volar を使うことによってほぼ解消されている props・emit の型補完が効く template 内の型補完もほぼ効く JSX ではないため slot の型補完はないがそこまで困らない emit の引数はコンポーネントをまたいだ場合の template の型補完は効かない、そこだけ注意

Slide 6

Slide 6 text

Slide 7

Slide 7 text

7 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 新しいビルドツール Vite の登場 Vite の開発体験が良い！使いたい！ ● Vite（というか esbuild）は HMR がとても速い ● 2022年からサービス開発するなら Vite 使うと楽 Frontend Weekly LT（社内勉強会）で「Vite」について LT しました - BASEプロダクトチームブログ ↑以前 Vite について調べた LT をしたので興味がある方はみてね

Slide 8

Slide 8 text

8 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 Nuxt3（RC）（まだ RC だけど）やっぱり Nuxt 使いたい ● SSR/SSG さまざまなユースケースに対応できる ● Nuxt3 だと Vue3 と Vite が使える！ ● そろそろ RC 外れることを信じてこの発表では一足先に Nuxt3 を使うことにしました（RC 外れるまでプロダクションでの利用は自己責任）

Slide 9

Slide 9 text

Slide 10

Slide 10 text

10 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 CSR(SPA) | SSR | SSG | ISG ● Client-side Only Rendering（SPA）: ○ SEO やページキャッシュの必要がない管理画面とかだったら SPA で十分 ● Server Side Rendering（SSR）: ○ Nuxt3 のメインは SSR。init するとデフォルトがこれになっている ● Static Site Generation（SSG）: ○ ブログやメディアサイトなど更新が頻繁ではないものは SSG も良い ● Incremental Static Generation（ISG）: ○ SSG と SSR のハイブリッドのような ISG も今後機能として出てきそう ○ まだ公式ドキュメントには登場していない（2022/10/28 時点）今回は SSR を選びましたが、要件次第では他の選択肢も参考： New Nuxt 3 Feature: Incremental Static Generation | Vue Mastery

Slide 11

Slide 11 text

11 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 ● SSR ○ AWS ○ GCP ○ Azure ○ Vercel edge functions ● CSR(SPA) or SSG ○ Vercel ○ Netlify 選択肢によって変わるデプロイ先今回は SSR のため Vercel edge functions を選びましたが、こちらも要件次第ではたくさんの選択肢も参考： Deployment · Nuxt それぞれのサービスでお値段・機能などが変わるため、どれを使うかは正直作るもの次第なところがとても大きいです。また連携する他 API やサービスによっても変わるため、フロントエンドというよりインフラに関わるお話です。

Slide 12

Slide 12 text

Slide 13

Slide 13 text

13 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 ディレクトリ構成 ● assets/ ● components/ ● composables/（合成関数置き場） ● content/（Nuxt Content の MD 置き場） ● layouts/ ● middleware/ ● pages/ ● plugins/ ● public/ ● server/ Nuxt のディレクトリ構成に沿ってこんな感じに参考： Nuxt Directory Structure Nuxt2 → Nuxt3 でいくつかサポートされるディレクトリが増えています init したばかりだとディレクトリが一つもないので自分で作る必要があります

Slide 14

Slide 14 text

14 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 ● components/ ○ ui/（UI コンポーネント） ■ button.vue とか input-text.vue とか ■ ゆくゆくは UI ライブラリ package として切り出せるような単位と考える ○ common/（共通コンポーネント） ■ item-select.vue とか user-card.vue とか ○ domain/（各画面の共通していないコンポーネント） ■ URL path と同じディレクトリ構造にする ■ items/list-container.vue とか ■ settings/account/password-update.vue とか components のディレクトリ構成推しの構成。3つのディレクトリでコンポーネントの責務を分ける

Slide 15

Slide 15 text

15 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 ● Presentational コンポーネント ○ 「表示」に責任を持つコンポーネント ■ props / emit をバケツリレーするだけ ● Functional コンポーネント ○ API 通信や emit された値を保持したりなど「機能」に責任を持つコンポーネント ○ XxxContaner.vue が一般的な命名 ○ スタイルはほぼ持たない（コンポーネント間の余白くらい） Tips: コンポーネント設計 💡 Presentational・Functional なコンポーネントを使い分けるこのようにコンポーネントの責務を分けて設計するとコードの見通しが良くなります。

Slide 16

Slide 16 text

Slide 17

Slide 17 text

17 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 逆に「見た目」にこだわりがないのなら既存のイケてる UI ライブラリを使って楽することもできます。どの UI ライブラリが良いかについては好みやほしい UI が用意されているかなどがあるため作りたい UI に沿って選定していきましょう。デザインシステム作るか作らないか「見た目」にこだわるならデザインシステム作ろう

Slide 18

Slide 18 text

18 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 まだ nuxt/storybook は Nuxt3 に対応していないため、 storybook/vue3 と @storybook/builder-vite を使って構築する。推しの Storybook アドオン： ● @storybook/addon-essentials ○ いろいろ入ってるパック、これさえあればとりあえず大丈夫 ● @storybook/addon-a11y ○ a11y のチェックアドオン、WCAG に対応しているかわかる ● @storybook/addon-interactions ○ インタラクションとテストのビジュアルデバッグが可能になる ● @storybook/addon-links ○ Story 間を移動するリンクを作成できるデザインシステムを作る場合 Storybook でコンポーネントカタログを作る

Slide 19

Slide 19 text

19 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 デザインシステムを作らない場合 ● 既存の UI ライブラリにある機能でまかなえる場合 ○ Vue3 で使える UI ライブラリは今どれくらいあるか... 🤔 ■ パッと調べたところ Ant Design Vue、BalmUI、 Element+、Oruga、PrimeVue、Vant、View UI Plus が Vue3 対応している ■ これらの中で機能を満たしてビジュアルが合うものを探す ● 既存の UI ライブラリにある機能でまかなえない場合 ○ Tailwind CSS、Windi CSS、Tachyons などの Pure CSS UI ライブラリを使って最低限見た目を整えて自作する ● Tailwind 系はデザインシステムを作る上で使ってもヨシ ○ デザインの逸脱を防ぐ目的で使うと効果的な UI ライブラリ ○ 参考： Tailwind考 - uhyo/blog UI ライブラリを選定する

Slide 20

Slide 20 text

Slide 21

Slide 21 text

21 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 ● VeeValidate 4 の Composition API ○ From コンポーネントを使うやり方と Composition API 対応の2種類あるが、Composition API 対応のほうは良さそう。 ● VeeValidate は 3 → 4 の破壊的変更がえげつなかったのが若干気がかり。次のバージョンアップの時は後方互換性が保たれているといいな... ● Vuelidate 2 ○ 関数だけ template に渡す形のライブラリ。使いやすい。フォームバリデーションライブラリどれを使うかはお好みだが、引き剥がしやすくなっているライブラリだと尚良し。 template で独自コンポーネントを使うようなライブラリだと引き剥がしづらいので要注意。

Slide 22

Slide 22 text

Slide 23

Slide 23 text

23 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 ● 親子関係のないコンポーネントをまたいだデータのやりとりをしたい場合は Pinia のような状態管理ライブラリを使う ● Provide/Inject を使ってもコンポーネントをまたいだデータのやり取りができるが、型推論が効かない（コンポーネントをまたぐと any になる）ため Pinia を使ったほうが良い Vuex と似ているが、TypeScript の型推論がサポートされて Composition API スタイルの API を提供するのが Pinia 状態管理は Pinia 一択

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

26 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 OpenAPI Generator を使って API Client と型を自動生成したものを使うと、API Client と型を自分で定義する必要がなくなります。別リポジトリで OpenAPI を管理し、 API Client と型を生成して packages として配信メインのリポジトリでは packages を import して使います。詳しい使い方はこちらの記事をどうぞ↓ OpenAPI Generator で API Client と型を自動生成した話スキーマ駆動開発で楽する API Client & Type Project OpenAPI

Slide 27

Slide 27 text

27 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 ● 良かった点 🙆 ○ API Client と型を手動で作成しなくて良くなった！ ○ 既存のスキーマとの乖離が減って管理がしやすくなった ● 悪かった点 🙅 ○ OpenAPI Generator で生成されるコードが難しい... ■ Enum の型変換がいまいちだった ● Enum じゃなくて Union Type で生成されてほしいよね ■ 生成されてほしいコードが生成されなかったり ● そもそも OpenAPI で正しく定義しないと正しい API Client は生成されないスキーマ駆動開発で楽する API Client と型を自動生成してみてどうだったか？🤔

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 テスティングライブラリ ● Integration・Unit テスト ○ Vitest や Testing Library Vue を使うと良い ● Visual Regression Test・End To End ○ VRT は Chromatic を使うと良い ■ これらについては後から入れるでも大丈夫フロントエンドにもテストがあるとデグレ防止や仕様がテストから読み取れて分かりやすくなるため、初期の段階からテスティングライブラリは入れておいたほうが開発がしやすいと考えています。テストがあることで安心して機能追加・修正ができます。

Slide 30

Slide 30 text

Slide 31

Slide 31 text

31 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 Linter・Formatter 入れないと後で後悔するもの No.1 ● eslint & prettier ○ yarn add -D eslint prettier @nuxtjs/eslint-config-typescript eslint-config-prettier eslint-plugin-nuxt eslint-plugin-vuejs-accessibility ● stylelint ○ yarn add -D stylelint @nuxtjs/stylelint-module stylelint-config-prettier はじめは「開発人数も多くないし良いや...」と後回しにしがちな Linter 系ですが、これこそ一番最初に入れておくと便利なツールです。特に Prettier での自動 Fix はとても開発体験の良いものです。リポジトリ作ってからまずはじめに設定しておくと、自動 Fix で差分が出て困ることがなくなるので初期の導入をおすすめします。

Slide 32

Slide 32 text

32 © 2012-2022 BASE, Inc. #vuefes_rejectcon2022 Volar VSCode を使っている人は Volar を入れると捗る！ Vue2 の頃は Vetur が主流だったが、今は公式が Volar を推している https://twitter.com/VueDose/status/1463169464451706897 余談ですが、Volar は Vue3 に限らず Vue2 でも使えます。 Vetur の開発はもう既に止まっているので Volar を使うと良さそうです。