Nuxt.js | みんたく

Intersection Observer APIを使用したGTM/GA4イベントトラッキングの実装

みんたく — Sun, 05 Jan 2025 01:50:27 +0000

Webサイトでユーザーの行動を分析する際、要素が画面に表示されたタイミングを検知したいと思い、Vue.jsのコンポーネントで Intersection Observer API を使用して要素の表示を検知し、Google Analytics 4（GA4）でトラッキングする実装方法を紹介します。

目的

カードコンポーネントの画面表示を検知
GTM経由でGA4にイベントを送信
表示データの分析

実装フロー

Vueコンポーネントで要素の表示を検知
dataLayerにイベントをプッシュ
GTMでイベントを捕捉
GA4にデータを送信

Vueコンポーネントの実装

import { ref, onMounted } from 'vue'

interface Props {
  items: Array<{
    id: string
    title: string
  }>
}

const props = defineProps()
const itemRefs = ref([])

onMounted(() => {
  itemRefs.value.forEach((elementRef, index) => {
    if (!elementRef) return

    const observer = new IntersectionObserver((entries) => {
      if (entries[0].isIntersecting) {
        const item = props.items[index]
        // dataLayerにイベントをプッシュ
        window.dataLayer?.push({
          event: 'item_view',
          item_id: item.id,
          item_title: item.title,
          eventModel: {
            send_to: 'G-XXXXXXXX'
          }
        })
        observer.disconnect()
      }
    })

    observer.observe(elementRef.$el || elementRef)
  })
})

ref配列の使用

itemRefs配列を使って、複数のカードコンポーネントへの参照を管理しています。Vue3のref属性の動的な割り当てを活用しています。

Intersection Observer APIの設定

各カードごとに個別のObserverを作成しています。一度表示を検知したらdisconnect()で監視を停止し、重複計測を防止します。

dataLayerへのデータ送信

カードのIDとタイトルを送信し、eventModelを使って送信先のGA4を指定しています。

GTMの設定

続いて、Google Tag Managerの設定手順です。

1. 変数の設定

まずは、dataLayerから送信されたデータを受け取るための変数を設定します。

GTMの変数設定で以下の2つを作成します。

【Item ID変数の設定】
- 変数名: Item ID
- 種類: データレイヤー変数
- データレイヤー変数名: item_id

【Item Title変数の設定】
- 変数名: Item Title
- 種類: データレイヤー変数
- データレイヤー変数名: item_title

これらの変数は、後ほどGA4にデータを送信する際のパラメータとして使用します。

2. トリガーの設定

次に、イベントを検知するためのトリガーを設定します。

【トリガーの設定】
- トリガー名: Item View
- トリガータイプ: カスタムイベント
- イベント名: item_view

このトリガーは、dataLayerにプッシュされたitem_viewイベントを検知します。

3. タグの設定

最後に、GA4にデータを送信するためのタグを設定します。

【タグの設定】
- タグ名: GA4 - Item View
- タグタイプ: Google タグ
- 測定ID: G-XXXXXXXX

イベントパラメータ:
- item_id: {{Item ID}}
- item_title: {{Item Title}}

GA4での設定と分析

カスタムディメンションの設定

GA4でデータを分析するために、まずカスタムディメンションを設定する必要があります。

管理画面から以下のディメンションを作成します。

Item ID（イベントスコープ）
Item Title（イベントスコープ）

レポートの作成

探索レポートを使って、以下のように分析が可能です。

ディメンション：Item Title
指標：イベントカウント
フィルター：イベント名 = item_view

これにより、各カードの表示回数を確認できます。

デバッグのポイント

1. GTMのプレビューモード

GTMのプレビューモードでは以下を確認します。

dataLayerにイベントが正しく送信されているか
変数が期待通りの値を取得できているか
タグが正しいタイミングで発火しているか

2. GA4のデバッグビュー

GA4のデバッグビューでは

イベントが正しく送信されているか
パラメータが正しく設定されているか

を確認できます。

よくあるトラブルと解決方法

イベントが発火しない

dataLayerの実装を確認
コンソールでエラーがないか確認

パラメータが取得できない

GTMの変数名が正しいか確認
dataLayerの構造を確認

GA4にデータが反映されない

測定IDが正しいか確認
最大48時間の遅延を考慮

→ 実際に24時間くらいデータが反映されず、実装が間違っているのかと見直していましたが時間が経てば反映されてました

参考リンク

交差オブザーバー API - Web API | MDN

交差オブザーバー API (Intersection Observer API)…

developer.mozilla.org

Google Analytics for developers | Google for Developers

developers.google.com

デベロッパー向け Google アナリティクス | Google Analytics | Google for Developers

developers.google.com

The post Intersection Observer APIを使用したGTM/GA4イベントトラッキングの実装 first appeared on みんたく.

Nuxt.jsのアプリケーションにVWOのA/Bテストツールを導入する

みんたく — Sun, 18 Aug 2024 07:14:46 +0000

サイト運営において、ユーザー体験の向上は欠かせない要素となっていますが、改善策を直感的に判断して実施するだけでは、その効果を正確に評価することは難しいと実感しています。

ユーザーの反応を正確に把握し、データに基づいた改善を行うためにも、A/Bテストを導入することにしました。

今回、VWO（Visual Website Optimizer）を利用してA/Bテストを実施する方法などについて説明します。

A/Bテストツールの導入でユーザー体験を向上させたい

運用しているサイトにおいて、改善する際にどうしても直感的に頼るところが出てきてしまい、改善した結果が本当に良い影響を与えているかどうかを確証できずにいました。

そこで、実際に改善した結果を元にユーザーフィードバックを収集できるA/Bテストを導入してみることにしました。

A/Bテストを導入することで、ユーザーが最も快適に感じるUI/UXやデザインを特定することができ、サイト全体の使いやすさやエンゲージメント率を高めることができます。

Googleオプティマイズの終了

A/Bテストツールの導入にあたり、広く使われていたGoogleオプティマイズを利用しようとしましたが、調べてみると2023年9月30日をもって廃止されていました。

Googleがこれらのツールが顧客のニーズに対応できていないと判断したためのようで、より包括的なテスト機能を提供するために、Google Analytics 4に注力することを決定したようです。

そのため、別のA/Bテストツールを探し、今回はVWOのA/Bテストツールを導入しました。理由としては、無料で利用できること、使いやすいUIであること、A/Bテストの他にヒートマップやパーソナライゼーションなど利用できるため、選定しました。

VWOのA/Bテストツールを導入する

実際に導入してみます。まずは以下からVWOのアカウントを作成します。

Launching a Free Plan for VWO Testing, a Better Google Optimize | VWO

VWO offers a free plan for VWO Testing t…

vwo.com

ヘッダーの「Start Free Trial」からアカウント作成していきます。

メールアドレスを入力して、「StartNow」を押します。メールアドレスに確認用のメールが届いているので、そこのURLにアクセスし、必要な情報を埋めたら登録完了です。

アカウント登録が完了したら、自分のサイトにVWOのスクリプトを導入します。WordpressなどのCMSを利用している場合は、プラグインなどで導入できるみたいです。

今回はNuxt3のアプリケーションなので、HTMLコードをの中に追加しました。正しく追加されると、緑枠のようにdetectedになります。

ダッシュボードからA/B Testsを選択します。右上の「Create」から新しいキャンペーンを作成します。

PagesからA/BテストしたいURLを入力します。URLのマッチパターンもいくつかあったり、除外したいページなども設定できます。

Variationタブでテストパターンを追加できます。また、Traffic spritでどのパターンにどのくらいの割合を流入させたいかの設定ができます。

テストパターンはEditから設定できます。GUIでテストパターンが作れるので、ノーコードでテスト設定ができます。

他にもMetricsでどの指標を基準にテストの成功を評価するかを指定したり、Audience and Trafficでどのユーザーにテストを表示するかや、トラフィックの何%にテストを適用するかを設定することができます。

最後に「Start test」のボタンを押したら、A/Bテストが開始されます。

アプリケーションがSSGの場合

ちなみにアプリケーションのレンダリング方法がSSGの場合、A/Bテスト導入したのにテストパターンが反映されないなど、うまくいかない場合があります。

SSGの場合事前にビルドして静的ファイルとして生成しているので、サーバーサイドでデータを書き換えることができないかと思います。

その場合は、plugins配下にvwo.client.tsのようなファイルを作成し、クライアントサイドでスクリプトを実行することになるかなと思います。

クライアントサイドで実行するので、オリジナルではないテストパターンの時は値やUIの更新などに少しラグが生じますが、一応導入することは可能です。

おわりに

A/Bテストツールの導入で、特に、直感に頼るだけでは得られない具体的なデータに基づく改善が可能になりました。

VWOのA/Bテストの設定は直感的でわかりやすく、今のところすごく使いやすいと感じています。

これからもA/Bテストを活用して、データに基づく継続的な改善を行い、ユーザーにとって快適で使いやすいサイト作りを目指していきたいです。

The post Nuxt.jsのアプリケーションにVWOのA/Bテストツールを導入する first appeared on みんたく.

実行環境によってFirebase環境の接続を切り替える

みんたく — Wed, 06 Dec 2023 04:26:18 +0000

今更ながらFirebaseの開発環境を用意して、実行環境によってアプリケーションとの接続を切り替えるようにしたので、メモ代わりに書きました。

開発環境のFirebaseを構築し、アプリケーション側を設定してきます。今回の目的として、ローカルでは開発環境のFirebaseに接続するようにし、本番では本番環境のFirebaseに接続するようにします。

実行環境によってFirebaseとの接続を切り替えるアプリケーション側の設定

CSR・SSRどちらでも利用したいものはpublicで、サーバーサイドのみ利用するものはprivateで環境変数をセットします。今回はSSGで、CSRでも利用するためにpublicで設定しています。

ここでは本番環境の値を定義しています。

・nuxt.config.ts

...

runtimeConfig: {
  public: {
    fbApiKey: 'xxxxxxxxxxxx',
    fbAuthDomain: 'xxxxxxxxxxxx',
    fbProjectId: 'xxxxxxxxxxxx',
    fbStorageBucket: 'xxxxxxxxxxxx',
    fbMessagingSenderId: 'xxxxxxxxxxxx',
    fbAppId: 'xxxxxxxxxxxx',
    fbMesurementId: 'xxxxxxxxxxxx'
  }
},

...

ローカル用の環境変数を用意して、そこに開発環境用のFirebase接続情報を定義しています。

NUXT_という接頭辞をつけると、ランタイム構成の環境変数を上書きできます。今回はpublic配下の環境変数を上書きするのNUXT_PUBLIC_の接頭辞をつけています。

・.env.local

NUXT_PUBLIC_FB_API_KEY=xxxxxxxxxxxx
NUXT_PUBLIC_FB_AUTH_DOMAIN=xxxxxxxxxxxx
NUXT_PUBLIC_FB_PROJECT_ID=xxxxxxxxxxxx
NUXT_PUBLIC_FB_STORAGE_BUCKET=xxxxxxxxxxxx
NUXT_PUBLIC_FB_MESSAGING_SENDER_ID=xxxxxxxxxxxx
NUXT_PUBLIC_FB_APP_ID=xxxxxxxxxxxx

最後にpackage.jsonの実行コマンドに–dotenvで.env.localを読み込むようにして完了です。こうすることで、.env.localの値が上書きされて、ローカル起動時にFirebaseの開発環境に接続して開発することができます。

・package.json

...

"scripts": {
  "dev": "nuxi dev --dotenv .env.local"
},

...

参考：

https://nuxt.com/docs/guide/going-further/runtime-config

The post 実行環境によってFirebase環境の接続を切り替える first appeared on みんたく.

より高度なSEO対策ができるuseSeoMetaを使ってみる

みんたく — Sat, 07 Oct 2023 07:51:45 +0000

Nuxt.jsの公式ドキュメントを見ていると、useSeoMetaというコンポーザブルがあり、気になったので調べて使ってみました。

そもそもuseHeadとuseSeoMetaでメタタグ生成するのに違いがあるの？

メタタグの生成時にはuseHeadを使っているのですが、そもそもuseHeadでメタタグ生成するのとuseSeoMetaで生成するのでは何か違いがあるのか分からず、調べてみました。

結論としては、どちらもSEOに関連するメタタグを生成できますが、useSeoMetaの方がより高度なSEO対策ができるみたいです。

useHead：Nuxt の標準的なヘッドコンポーネントでメタタグ、リンクタグ、スタイルタグなどを生成できる
useSeoMeta：SEOに関連するメタタグを生成するための専用コンポーネントでuseHeadよりも多くの機能を提供できる

https://nuxt.com/docs/api/composables/use-seo-meta

useServerSeoMetaとuseSeoMetaの違いは？

もう少し調べてみると、useServerSeoMetaというのもあり、useSeoMetaの違いを調べてみました。

useServerSeoMeta は、SSRで使用することを想定されています。サーバー側でメタタグを生成するため、パフォーマンスへの影響が少なく、カスタマイズが容易です。

useSeoMeta は、SPAで使用することを想定されています。クライアント側でメタタグを生成するため、パフォーマンスへの影響があるものの、カスタマイズが難しいというデメリットがあります。

useServerSeoMeta：サーバー側でメタタグを生成する。つまり、ページのHTML が生成されるタイミングでメタタグが生成される
useSeoMeta：クライアント側でメタタグを生成する。つまり、ユーザーがページを読み込むたびに、メタタグが生成される

https://nuxt.com/docs/getting-started/seo-meta#useseometa-and-useserverseometa

useServerSeoMetaを使ってみる

使い方はuseHeadで使っていたときみたいに、useServerSeoMetaの中に定義されているプロパティに対する値を入れてあげるだけです。

パラメータは100以上あり、詳しくはこちらを参照してください。

https://github.com/harlan-zw/zhead/blob/main/src/metaFlat.ts

SSGでuseServerSeoMetaを使うと

SSGでどうなるか使ってみたのですが、発見があったのでまとめておきます。

useFetchしてコンテンツを取得して生成するページに関してはuseServerSeoMetaでメタタグ生成されましたが、サービス紹介ページのようなHTMLベタばりのページをSSGした場合は、useServerSeoMetaでメタタグ生成されないことがわかりました。

てっきりSSGの処理的には全ページをサーバー側で静的ページにビルドしていると思っていました。これはSSGでgenerateしてる時に、元々静的なページに関してはサーバー側で呼び出されてないのか分からないのですが、挙動が違ったことがわかりました。

useFetchしない静的ページに関してはuseSeoMetaを使うなどの使い分けが必要なのでしょうか。この辺り詳しい人に裏側でどうなっているのか聞いてみたいです。

The post より高度なSEO対策ができるuseSeoMetaを使ってみる first appeared on みんたく.

改めて運営しているWebサービスのアーキテクチャを整理する

みんたく — Fri, 19 May 2023 11:35:02 +0000

最近、NetlifyからFirebase Hostingに移行したり、認証機能を追加実装したりとアーキテクチャがちょっと変わってきたので、改めて整理したいと思います。

今のざっくりアーキテクチャ図

こちらの記事で書いてありますが、元々Netlifyを使用していましたが、Firebase Hostingに移行しました。

NetlifyからFirebase Hostingに移行した話

満を辞して？NetlifyからFirebase Hostingに移行したので、メ…

mintaku-blog.net

基本SSGの構成は変わっておらず、後で説明しますが、一部SPA的なページが追加されました。

流れとしてはmainブランチにプッシュされるとGithub Actionsのパイプラインが動き出し、ビルドが始まります。

ビルド時はContenfulからデータを取得して、静的なページを生成していきます。ページの生成が完了すると、Firebase Hostingにデプロイします。

ページ数は今のところ大体3300ページくらいあり、ビルドしてデプロイするまで20分近くかかっており、長すぎるビルド時間が直近の課題となっています。

今考えているアプローチ方法は、ISGの導入や最近Nuxt3機能追加されたpayloadを使うなど、サーバー通信を減らしていきたいと思っています。

認証機能のところ

今回新しく追加した認証機能はFirebase Authenticationを使いました。Firebaseに統合したいのもあって、ホスティングサービスもNetlifyからFirebase Hostingに移行した感じです。

1stリリースでは、認証のプロバイダはGoogleとTwitterのみにしています。後々、メールアドレスや他のSNS認証も追加する予定です。

ユーザー情報などの格納データはFirestoreを使っています。Firebase Authenticationとあわせて開発しやすかったです。

今後のアーキテクチャについて

今後の開発において、ますます動的な機能が増えていくと思います。今はサーバーレスのSSGで開発していますが、後々はAPIを立てたり、SSRに変更するなど考えています。

新しい技術なども出てきたりすると思うので、臨機応変にその時その時考えて、アーキテクチャや使用技術を決めていきたいと思います。

また、負債を残さないためにもdependabotの導入によるライブラリのバージョンアップやこまめなリファクタリングなど、開発生産性を高く保ちながらより良いサービスを提供していきたいです。

The post 改めて運営しているWebサービスのアーキテクチャを整理する first appeared on みんたく.

Nuxt3で何となく使っているところをちゃんと理解する

みんたく — Sun, 26 Mar 2023 06:46:38 +0000

プライベートでNuxt3を使って開発していますが、何となく使っているところがあるのでちゃんと理解するために調べたり動かしたりして理解を深めました。

nuxt-linkの挙動について

何となく内部のリンクはnuxt-linkを使っていましたが、改めて挙動について深掘りしてみました。

NuxtのSSRでは初回読み込み時はサーバー側でレンダリングされて返却されます。aタグで遷移した際もサーバー側でレンダリングされますが、nuxt-linkを使った場合は、APIからのデータフェッチなどサーバー側で実行されずにクライアントで実行されています。

そのため、nuxt-linkを使って遷移した先のページは同期的に生成されておらず、変数などちょっと遅れてシュッと入ってくる感じになっています。開発者ツールでnetworkタブを見てみてもnuxt-linkで遷移した時はクライアントサイドでAPIが呼び出されていることが確認できます。

まあたしかに内部リンクへの遷移は特にSEOを気にすることもないので、SSRしてサーバー側への負荷をかける必要がないのでしょう。

ちなみに調べてみるとnuxt-linkでto propsに外部リンクを指定することもでき、外部リンクの場合は通常のaタグのように動作するそうです。

そのため、特に内部リンクと外部リンクでタグを使い分ける必要はないみたいですね。

疑問と仮説

ただSSGでやっているとnuxt-linkで遷移すると一瞬画面が表示されてそのあと画面が真っ白になりました。

これは遷移後にCSRでAPIコールしており、Netlifyをホスティングサービスとして使っているとサーバーを用意していないためにエラーになっていると思われます。

ローカルでは問題ないのですが、ローカルはSSRモードで動いているからだと思われます。

aタグだと問題ないため、あくまでも仮説ですが、SSGの場合はuseFetchをサーバーのみにするかuseAsyncDataにキャッシュキーを指定してあげれば再度呼ばれることもなく正常に動作するのかもしれないと思いました。

`追記`

そもそもSSGでserverディレクトリを使うこと自体想定されていないのかもしれないです。

Webサーバー用意してないのにserverディレクトリ使ってAPIコールする構成自体を見直すべきかもと思いました。

pluginとmiddleware

pluguinとmiddlewareの挙動の違いとかも何となく使い分けていたので、改めて調べてみました。

pluguinはアプリケーションの初期化時に実行してくれるもので、アプリケーション全体で利用するものはここでまとめて定義します。ちなみにファイル名の前に数字を付けることで、pluginが登録される順序を制御できます。

middlewareはページ遷移にあたって行う共通処理を記述することができます。middlewareを利用することでページ間の移動、サイトへのアクセス時にページを表示する前に事前に設定していた処理を行うことができます。

どちらもデフォルトではサーバーサイド、クライアントサイド双方で実行されます。ファイル名にclientとかserverとかつけるとそれぞれのみで実行されます。

改めて調べるとそれぞれの挙動を理解できて、ちゃんと使い分けができそうです。

https://nuxt.com/docs/guide/directory-structure/plugins

https://nuxt.com/docs/guide/directory-structure/middleware

useFetchとuseAsyncData

どちらを使えばよいか適切なタイミングがいまいちよくわかってないので調べてみました。

結論から言うとuseFetchは、$fetchを使ったデータ取得に特化した useAsyncDataのラッパー関数なので、基本的にデータを取得するだかならuseFetchを使えば良さそうです。

ここでいう$fetchとはofetchライブラリのことで、これは様々な環境で使用できるFetchAPIです。axiosのようなものみたいです。

useAsyncDataはどうやって使うかというと、以下のように引数を2つ取ります。

const { data, pending, error, refresh } = await useAsyncData(
  'test',
  () => $fetch('https://example.com/test')
)

第1引数はキーを指定し、内部でキャッシュを保持しています。それによって2回目以降はAPIにリクエストをすることなく、前と同じ結果を返してくれます。このキャッシュはNuxt内部で保持するため、キャッシュを区別するための一意なキーが必要となります。

第2引数は非同期処理を行う関数を指定しています。

useAsyncDataの第二引数が() => $fetchになるのであれば基本的にuseFetchを使用すれば問題なさそうです。

The post Nuxt3で何となく使っているところをちゃんと理解する first appeared on みんたく.

Nuxt3 + Firebase Authenticationで認証機能を実装する

みんたく — Wed, 04 Jan 2023 07:53:31 +0000

前提の話

Firebaseの初期化の設定などはここでは省略します。今回はGoogleアカウントでの認証を例にメモ的な感じでまとめています。

実装としてはGoogleアカウントで認証し、登録情報をFirestoreに登録するといった流れです。

NuxtとFirebaseのバージョンは以下の通りです。

Nuxt: 3.0.0
Firebase: 9.15.0

Googleアカウントで認証する

Googleアカウントで登録する流れを実装していきます。

まずは登録するための画面をcomponentsに作成します。このコンポーネントはpagesで呼び出すイメージです。

「Googleで登録」のボタンを押下するとgoogleSignUpメソッドが呼び出されます。ここでのuseAuth()とgoogleSignUpメソッドは後ほど実装していきます。

・components/SignUpForm.vue

「Googleで登録」のボタンを押下したgoogleSignUpメソッドがここで呼ばれます。GoogleAuthProviderのインスタンスを作成し、signInWithPopupを呼び出すことで、Google認証にポップアップが表示されます。

Google認証が完了したら、そのデータを元にgetUserメソッドでFirestoreのデータを取得しにいきます。

既にFirestoreにデータがある場合は、認証完了済みなのでログイン画面に遷移させます。データがない場合は新規登録なので、新しくFirestoreにuserデータを登録し、mypage画面に遷移させます。

最後にupdateUserメソッドを呼び出し、useState() を使ってuserの状態管理をしています。alertのところはいい感じのポップアップかトーストを実装したいところです。

・composables/useAuth.ts

import {
  Auth,
  User,
  UserCredential,
  onAuthStateChanged,
  signInWithPopup,
  GoogleAuthProvider,
} from "firebase/auth";
import { computed, ref } from "vue";
import {
  collection,
  where,
  query,
  getDocs,
  addDoc
} from '@firebase/firestore';
 
export function useAuth() {
  const { $auth, $firestore } = useNuxtApp()
  const user = ref($auth.currentUser);
  const isAuthed = computed(() => !!user.value);
  const db = $firestore;
 
  $auth.onIdTokenChanged((authUser) => (user.value = authUser));
 
  // ユーザー情報取得
  const getUser = async (uid: string): Promise => {
    const q = query(
      collection(db, 'users'),
      where("uid", "==", uid)
    );
    const querySnapshot = await getDocs(q);
 
    return querySnapshot.docs[0]
  };
 
  // ユーザー作成
  const createUser = async (user: UserCredential) => {
    await addDoc(collection(db, 'users'), {
      uid: user.user.uid,
      name: user.user.displayName,
      email: user.user.email,
      photo: user.user.photoURL
    })
  };
 
  // Google新規登録
  async function googleSignUp() {
    try {
      const provider = new GoogleAuthProvider();
      const googleUser = await signInWithPopup($auth, provider);
      const user = await getUser(googleUser.user.uid)
      const { updateUser } = await useUser()
      if (user) {
        alert("既にユーザー登録されています。")
        updateUser(user.data())
        navigateTo("/login", { replace: true })
      } else {
        alert("新規登録完了しました")
        await createUser(googleUser)
        const user = await getUser(googleUser.user.uid)
        updateUser(user.data())
        navigateTo("/mypage", { replace: true })
      }
    } catch (error) {
      throw error;
    }
  }
 
  async function currentUser() {
    return $auth.currentUser
  }
 
  return { isAuthed, user, checkAuthState, googleSignUp, currentUser };
}

updateUserメソッドを使ってuserのstateの状態を管理しています。

認証後はuserのstateにUser情報を入れ、ログアウトなどの認証情報が破棄された場合はnullを入れます。

・composables/useUser.ts

import { User } from "firebase/auth"
import { Ref } from "vue"

export const useUser = () => {
  const user: Ref = useState('user')

  const updateUser = (user: Ref) => (value: User | null) => {
    user.value = value
  }

  return {
    user: readonly(user),
    updateUser: updateUser(user)
  }
}

認証状態のチェック

認証後のマイページに認証されていない場合はアクセスできないようにしたい場合、認証状態をチェックするなどの処理が必要になります。

その場合はmiddlewareで認証状態をチェックし、認証されていない場合はログインページに遷移させるなどの処理を実装します。

definePageMetaで指定してあげることで、このmiddlewareの処理が実行されます。

また、ログイン済みの場合にログインページを表示する場合は、マイページに遷移させるなどの処理も必要になるかと思います。

・middleware/auth.global.ts

export default defineNuxtRouteMiddleware(async () => {
  if (!process.server) {
    const { isAuthed, checkAuthState } = useAuth();
    await checkAuthState();

    if (!isAuthed.value) {
      window.location.href = "/login";
    }
  }
});

全てのルートで実行したい処理がある場合は、Nuxt3のグローバルミドルウェアを使うことで実現できます。

.globalが付いたファイルは呼び出し処理を書かずに全てのルートで実行されます。

・middleware/auth-check.global.ts

export default defineNuxtRouteMiddleware(async () => {
  if (!process.server) {
    const { checkAuthState } = useAuth();
    await checkAuthState();
  }
})

The post Nuxt3 + Firebase Authenticationで認証機能を実装する first appeared on みんたく.

Nuxt3への移行作業時に気になったところをまとめてみた

みんたく — Wed, 12 Oct 2022 02:55:21 +0000

Nuxt2で開発したWebサービスをNuxt3 RCに移行作業を行なっているので、その際に気になった機能などをまとめておきます。

公式ページ：https://v3.nuxtjs.org/

Nuxt2との違い

Nuxt3は、Vue3をベースになっています。Nuxt2との違いとしてSSRの高速化やバンドルサイズの縮小などのパフォーマンスの向上、Composition APIの導入、TypeScript サポートなどが挙げられます。

v3.0.0-rc.10でFull SSGモードに

rc.3で開発していたのですが、SSGしてもクライアント側でデータフェッチしている挙動があり、どうにかならないかと悩んでいました。

Nuxt3のRC情報を見ていたら、SSG後にクライアント側で再フェッチしないFull SSGモードなるものがリリースされており、バージョンを上げたところ無事解決しました。

https://github.com/nuxt/framework/discussions/7513

Nuxt3のコアパッケージ

Nuxt3を構成するコアパッケージは以下のようになっています。

コアエンジン: nuxt
バンドラー: @nuxt/vite-builder and @nuxt/webpack-builder
コマンドライン: nuxi
サーバーエンジン: nitro
開発キットt: @nuxt/kit
Nuxt 2ブリッジ: @nuxt/bridge

nuxt/bridge

既存のNuxt 2プロジェクトからNuxt3の機能を使いたい場合はNuxt Bridge を使用するのが良さそうです。変更を最小限に抑えながら、ほとんどの新機能を試すことができます。

nitro

nitro(読み方はニトロじゃなくてナイトロ)の基盤は、rollupとh3で、高いパフォーマンスと移植性のために構築された最小限のhttpフレームワークです。特徴は以下の通りです。

クロスプラットフォームサポート

様々なプラットフォームにも対応しているエンジンで、JavaScript をサポートする様々なシステムでデプロイできます。

サーバーレスサポート

サーバーレス環境でも動作します。

API routes

unjs/h3プロジェクトを使用し、h3という軽量のhttp サーバーが使われています。

自動コード分割

設定しなくても自動的にコード分割してくれます。

ホットリロード

プログラム実行中にコードを変更できます。

ハイブリッド・モード

ページのレンダリングを細かくコントロールし、静的サイトとサーバーレスサイトでハイブリッドモードが使用可能です。

ローカル開発時のホットリロードの速度、CICD 上でのビルド実行速度が従来の WebPack とは段違いに速いと感じます。

Nitro - Next Generation Server Toolkit

Create web servers with everything you n…

nitro.unjs.io

自動インポート

Nuxt3では、CompositionAPIのsetupで使用する関数のインポートを追加する必要はなく、エンジンによって自動的にインポートされます。また、ディレクトリとファイル名で自動的にComponentもインポートされます。

components

インポートしたい Vue コンポーネントを配置するディレクトリ

composables

各コンポーネントを記入しなくても、Composables ディレクトリを使って自動的にインポートできる

ネスト化されたコンポーネント

ネスト化されたディレクトリにコンポーネントがある場合は、パス・ディレクトリのコンポーネントの名前を指定するだけで使用できます。

例えば、components/bar/foo.vue の場合、以下のようになります。

アトミックデザインでディレクトリを分けてファイルを作成する際はみたいな感じになりそうですね。ちょっと冗長になりそうな気もしています。

The post Nuxt3への移行作業時に気になったところをまとめてみた first appeared on みんたく.

Nuxt3に乗り換えてみてどう変わったか簡単にまとめる

みんたく — Sun, 06 Mar 2022 12:46:03 +0000

TypeScriptでフロント開発するにあたって、TypeScriptファーストなNuxt3を使いNuxt2からどう変わったのかなどを簡単にまとめてみました。

公式ドキュメント：https://v3.nuxtjs.org/

Nuxt3でどう変わった

Nuxt3になったことで、JSX/TSXやSCSSの対応、APIサーバー作成などの機能がデフォルトで含まれています。Nuxt2もセットアップなしで開発を始められるフレームワークでしたが、TypeScriptやSCSSで書く場合は別途追加する必要がありました。

Nuxt3によってそれらが内包され素早いフロント開発に着手できるようになりました。

※ JSXはJavaScripでHTMLっぽいのが書けるようJavaScriptを拡張したものです。TSXはJSXのTypeScript版です。

サーバー起動とホットリロードが早い

Nuxt3は開発時のビルドツールにViteが採用されています。そのため開発時のサーバー起動とHMRが早くなりました。

これは実際に使ってみて早さを実感しており、これだけでもNuxt3に乗り換える価値がありそうです。

Composition APIの採用

Composition APIは関数ベースでコンポーネントを実装する機能です。関数ベースであるため機能の再利用性を高める役割を持っています。

Vueでの新しい書き方としてプラグインでVue 2にも先行提供されていたComposition APIはNuxt3では標準採用されています。

従来の記法であるOptions APIと比較してTypeScriptの相性がいいことが挙げられます。 Options APIにTypeScript を導入しても thisやdataなどのoptionsの定義が複雑であるため、型定義が難しかったのですが、Composition APIを使用することで型推論でき開発が効率的になりました。

状態管理としてuseStateとpiniaが追加

Vue3ではVuexに代わってuseStateとpiniaが推奨されています。

Nuxt 2では主要機能の1つとして組み込まれていたVuexですが、グローバルな状態管理ストアにアプリが依存するリスクやTypeScript、単体テストとの相性の悪さなどがVuexが推奨されなくなった背景とされています。

Nuxt3でプロジェクトを作成する

Nuxt3 からは create-nuxt-app の代わりにNuxt CLIでNuxtプロジェクトを作成します。

npx create-nuxt-appによる質問がなくなったため、すぐにプロジェクトを作成できます。Nuxt3ではTypeScriptはデフォルトになっており、TypeScriptファーストなフレームワークになりました。

$ npx nuxi init sample-nuxt3-app

Nuxt3では生成されるファイルが.tsで作られていることがわかります。

.gitignore
README.md
app.vue
nuxt.config.ts
package-lock.json
package.json
tsconfig.json

JSX・TSXを使うなら

JSX・TSXを使う場合は、tsconfig.jsonにcompilerOptionsを追記することが使用することができるようになります。

{
  // https://v3.nuxtjs.org/concepts/typescript
  "extends": "./.nuxt/tsconfig.json",
  + "compilerOptions": {
  +   "jsx": "preserve"
  + }
}

The post Nuxt3に乗り換えてみてどう変わったか簡単にまとめる first appeared on みんたく.

【Nuxt.js】JestでTDDを実践してみる

みんたく — Sun, 27 Jun 2021 13:42:53 +0000

JestでTDDを実践しながらNuxt.jsで簡単なToDoリストをつくってみました。

ToDoリストのストーリーを考える

Nuxt.jsで簡単なToDoリストをつくりにあたり、ユーザーストーリーを考えます。考えた結果、以下のストーリーができました。

ユーザーはフォームと作成ボタンを見ることができる
ユーザーはToDoタスク一覧と完了タスク一覧を見ることができる
ユーザーはフォームにタスクを入力して作成ボタンを押すと、ToDoタスク一覧に追加されることを確認できる
ユーザーはフォームにタスクが入力していない場合は、作成ボタンを押すことができない
ユーザーはToDoタスクの完了ボタンを押すと、完了タスク一覧にタスクが移動されることを確認できる
ユーザーは完了タスクのToDoに戻すボタンを押すと、ToDoタスク一覧にタスクが移動されることを確認できる

ToDoリストの画面は、TaskFormコンポーネントとTaskListコンポーネントに分けて実装します。

またタスクのデータはFirestoreに格納するようにし、REST APIでデータを操作します。

Nuxt.jsやJestのインストールやFirestoreのセットアップなどは省略しています。

「ユーザーはフォームと作成ボタンを見ることができる」のテストを書く

まず「ユーザーはフォームと作成ボタンを見ることができる」のテストを書いていきます。

TaskFormコンポーネントを作成し、タスク入力フォームと作成ボタンが存在することをチェックします。

・components/TaskForm.spec.js

import { mount } from '@vue/test-utils'
import TaskForm from '@/components/TaskForm.vue'

describe('components/TaskForm.vue', () => {
  let wrapper
  beforeEach(() => {
    wrapper = mount(TaskForm)
  })

  describe('template', () => {
    test('タスク入力フォームが存在すること', () => {
      const form = wrapper.find('input');
      expect(form.exists()).toBe(true);
    })

    test('タスク作成ボタンが存在すること', () => {
      const button = wrapper.find('input');
      expect(button.exists()).toBe(true);
   })
  })
})

テストを作成したら実際にテストを実行してみます。TDDでいうレッドのところです。

まだ実装はしていないので全部のテストが失敗しますが、期待通りの落ち方をしているかを確認します。

FAIL  components/TaskForm.spec.js
  components/TaskForm.vue
    template
      ✕ タスク入力フォームが存在すること (10 ms)
      ✕ タスク作成ボタンが存在すること (1 ms)

  ● components/TaskForm.vue > template > タスク入力フォームが存在すること

    expect(received).toBe(expected) // Object.is equality

    Expected: true
    Received: false

      16 |     test('タスク入力フォームが存在すること', () => {
      17 |       const form = wrapper.find('input');
    > 18 |       expect(form.exists()).toBe(true);
         |                             ^
      19 |     })
      20 |
      21 |     test('タスク作成ボタンが存在すること', () => {

      at Object. (components/TaskForm.spec.js:18:29)

  ● components/TaskForm.vue > template > タスク作成ボタンが存在すること

    expect(received).toBe(expected) // Object.is equality

    Expected: true
    Received: false

      21 |     test('タスク作成ボタンが存在すること', () => {
      22 |       const button = wrapper.find('input');
    > 23 |       expect(button.exists()).toBe(true);
         |                               ^
      24 |     })
      25 |
      26 |   })

      at Object. (components/TaskForm.spec.js:23:31)

存在していない、実装されていないなどの落ち方をしていればひとまず完了です。

「ユーザーはフォームと作成ボタンを見ることができる」を実装する

テストで書いたシナリオを元にTaskFormコンポーネントを実装してきます。今回は簡易的なHTMLでフォームとボタンを作成しました。

・components/TaskForm.vue

「ユーザーはフォームと作成ボタンを見ることができる」をテストする

実装が終わったら、再度TaskFormのテストを流してみます。TDDでいうグリーンのところです。

テストが全て通ったらこのストーリーの実装は完了です。必要に応じてリファクタリングをします。

PASS  components/TaskForm.spec.js
  components/TaskForm.vue
    template
      ✓ タスク入力フォームが存在すること (9 ms)
      ✓ タスク作成ボタンが存在すること (1 ms)

「ユーザーはToDoタスク一覧と完了タスク一覧を見ることができる」のテストを書く

次に「ユーザーはToDoタスク一覧と完了タスク一覧を見ることができる」のテストを書いていきます。

TaskListコンポーネントでToDoリストと完了リストを表示するようにします。

そのため、ToDoリストと完了リストにFirestoreに格納されているデータをfetchしてくるようにします。

・components/TaskList.spec.js

import Vuex from 'vuex'
import { mount, createLocalVue} from '@vue/test-utils'
import * as indexStore from '@/store'
import TaskList from '@/components/TaskList.vue'

const localVue = createLocalVue()
localVue.use(Vuex)

describe('components/TaskList.vue', () => {
  let wrapper
  let store
  let todoTask
  let doneTask
  beforeEach(() => {
    store = new Vuex.Store(indexStore)
    todoTask = { id: '1', content: 'content_1', status: 'todo' }
    doneTask = { id: '2', content: 'content_2', status: 'done' }
    wrapper = mount(TaskList, {
      store: store,
      localVue
    })
    store.replaceState({ tasks: [todoTask, doneTask] })
  })

  describe('template', () => {
    test('todoリストが表示されること', () => {
      const li = wrapper.find('li.todo')
      expect(li.find('span').text()).toBe(todoTask.content)
      expect(li.find('button).text()).toBe('完了')
    })

    test('完了リストが表示されること', () => {
      const li = wrapper.find('li.done')
      expect(li.find('span').text()).toBe(doneTask.content)
      expect(li.find('button).text()).toBe('ToDoに戻す')
    })
  })

  describe('script', () => {
    describe('computed', () => {
      describe('todos', () => {
        test('storeからtodoTasksが取得できること', () => {
          expect(wrapper.vm.todoTasks).toEqual(expect.arrayContaining([todoTask]))
        })
        test('storeからdoneTasksが取得できること', () => {
          expect(wrapper.vm.doneTasks).toEqual(expect.arrayContaining([doneTask]))
        })
      })
    })
  })
})

タスクリストの状態管理をするストアのテストを書きます。

ステータスの状態によってToDoタスクと完了タスクを出し分けるようにします。

Storeではaxiosを使って外部サービスにHTTPリクエストしているためaxiosをモック化してテストしています。

async/awaitでaxiosの非同期処理を実現し、結果をgettersから取り出し比較します。

参考：https://github.com/nuxt-community/axios-module/issues/105

・store/index.spec.js

import Vuex from 'vuex'
import * as index from '@/store'
import { createLocalVue } from '@vue/test-utils'
import _ from 'lodash'
import axios from 'axios'

const localVue = createLocalVue()
localVue.use(Vuex)

let mockAxiosGetResult
jest.mock('axios', () => ({
  get: jest.fn(() => Promise.resolve(mockAxiosGetResult))
}))

let action
const testedAction = (context = {}, payload = {}) => {
  return index.actions[action].bind({ $axios: axios })(context, payload)
}

describe('store/index.js', () => {
  let store
  let todoTask, doneTask
  beforeEach(() => {
    store = new Vuex.Store(_.cloneDeep(index))
    todoTask = { id: '1', content: 'content_1', status: 'todo' }
    doneTask = { id: '2', content: 'content_2', status: 'done' }
  })

  describe('getters', () => {
    let tasks
    let todoTasks
    let doneTasks
    beforeEach(() => {
      tasks = [todoTask, doneTask]
      todoTasks = [todoTask]
      doneTasks = [doneTask]
      store.replaceState({
        tasks,
        todoTasks,
        doneTasks
      })
    })

    describe('todoTasks', () => {
      test('statusがtodoのtaskが取得できること', () => {
        expect(store.getters['todoTasks']).toContainEqual(todoTask)
        expect(store.getters['todoTasks']).not.toContainEqual(doneTask)
      })
    })
    describe('doneTasks', () => {
      test('statusがdoneのtaskが取得できること', () => {
        expect(store.getters['doneTasks']).not.toContainEqual(todoTask)
        expect(store.getters['doneTasks']).toContainEqual(doneTask)
      })
    })
    describe('tasks', () => {
      test('すべてのtasksが取得できること', () => {
        expect(store.getters['tasks']).toEqual(
          expect.arrayContaining(tasks)
        )
      })
    })
  })

  describe('actions', () => {
    let commit
    beforeEach(() => {
      commit = store.commit
    })

    describe('fetchTasks', () => {
      test('tasksが取得できること', async () => {
        action = 'fetchTasks'
        mockAxiosGetResult = {
          data: {
            documents: [
              {
                name: `tasks/${todoTask.id}`,
                fields: {
                  content: { stringValue: todoTask.content },
                  status: { stringValue: todoTask.status }
                }
              },
              {
                name: `tasks/${doneTask.id}`,
                fields: {
                  content: { stringValue: doneTask.content },
                  status: { stringValue: doneTask.status }
                }
              }
            ]
          }
        }

        await testedAction({ commit })
        expect(store.getters['tasks']).toEqual([todoTask, doneTask])
      })
    })
  })
})

テスト結果を省略していますが、ここでまたテストを実行し期待通りに落ちているかを確認します。

「ユーザーはToDoタスク一覧と完了タスク一覧を見ることができる」を実装する

テストが書いたシナリオを元にTaskListコンポーネントとindexページ、indexストアを実装してきます。

TaskListコンポーネントではToDoリストと完了リストがあり、indexページではTaskListコンポーネントとTaskFormコンポーネントを呼び出してタスクをストアから呼び出すようにします。

indexストアではFirestoreからデータを取ってきてToDoタスクと完了タスクに状態管理するようにします。

・components/TaskList.vue

・pages/index.vue

・store/index.spec.js

import _ from 'lodash'

export const state = () => ({
  tasks: []
})

export const getters = {
  tasks: state => state.tasks,
  todoTasks: state => state.tasks.filter(task => task.status === 'todo'),
  doneTasks: state => state.tasks.filter(task => task.status === 'done')
}

export const mutations = {
  updateTasks(state, tasks) {
    state.tasks = tasks
  }
}

export const actions = {
  async fetchTasks({ commit }) {
    await this.$axios.get(`/tasks`, {
      baseURL: process.env._AXIOS_BASE_URL_
    })
      .then(res => {
      let tasks = []
      if (_.has(res.data, 'documents')) {
        tasks = res.data.documents.map(doc => {
          return {
            id: _.last(doc.name.split('/')),
            content: doc.fields.content.stringValue,
            status: doc.fields.status.stringValue
          }
        })
      }
      commit('updateTasks', tasks)
    })
  }
}

「ユーザーはToDoタスク一覧と完了タスク一覧を見ることができる」をテストする

実装が終わったら再度テストを流します。テストが全て通ればこのストーリーは完了です。

PASS  components/TaskList.spec.js
  components/TaskList.vue
    template
      ✓ todoリストが表示されること (13 ms)
      ✓ 完了リストが表示されること (2 ms)
    script
      computed
        todos
          ✓ storeからtodoTasksが取得できること (2 ms)
          ✓ storeからdoneTasksが取得できること (1 ms)

PASS  store/index.spec.js
  store/index.js
    getters
      todoTasks
        ✓ statusがtodoのtaskが取得できること (3 ms)
      doneTasks
        ✓ statusがdoneのtaskが取得できること (1 ms)
      tasks
        ✓ すべてのtasksが取得できること (1 ms)
    actions
      fetchTasks
        ✓ tasksが取得できること

「ユーザーはフォームにタスクを入力して作成ボタンを押すと、ToDoタスク一覧に追加されることを確認できる」のテストを書く

先ほどTaskFormコンポーネントに作成したフォームに入力して作成ボタンを押すとToDoタスク一覧に追加されることが確認できるテストを書きます。

・components/TaskForm.spec.js

import Vuex from 'vuex'
import { mount, createLocalVue } from '@vue/test-utils'
import * as store from '@/store'
import TaskForm from '@/components/TaskForm.vue'

const localVue = createLocalVue()
localVue.use(Vuex)

describe('components/TaskForm.vue', () => {
  let wrapper
  beforeEach(() => {
    wrapper = mount(TaskForm, {
      store: store,
      localVue
    })
  })

  describe('template', () => {
    
...

    describe('タスク入力がある場合', () => {
      beforeEach(() => {
        const mock = jest.fn()
        wrapper.vm.addTask = mock
        wrapper.find('input').setValue('content')
      })

      test('dataに入力が反映されること', () => {
        expect(wrapper.vm.taskForm.content).toBe('content')
      })

      test('タスク作成ボタンを押下するとaddTaskが呼ばれること', () => {
        wrapper.find('button').trigger('click')
        
        expect(wrapper.vm.addTask).toHaveBeenCalled()
      })
    })
  })

  describe('script', () => {
    describe('data', () => {
      test('dataの構造が正しいこと', () => {
        expect(wrapper.vm.$data).toHaveProperty('taskForm.content')
      })
    })
  })
})

ストアのテストでは作成ボタンが押下された際にFirestoreに入力されたタスクのデータが保存されることを確認します。

・store/index.spec.js

import Vuex from 'vuex'
import * as index from '@/store'
import { createLocalVue } from '@vue/test-utils'
import _ from 'lodash'
import axios from 'axios'

const localVue = createLocalVue()
localVue.use(Vuex)

let mockAxiosGetResult
jest.mock('axios', () => ({
  
...

  post: jest.fn(() => Promise.resolve(mockAxiosGetResult))
}))

let action
const testedAction = (context = {}, payload = {}) => {
  return index.actions[action].bind({ $axios: axios })(context, payload)
}

describe('store/index.js', () => {

...

  describe('actions', () => {
    let commit
    beforeEach(() => {
      commit = store.commit
    })

...

    describe('createTask', () => {
      test('taskが追加されること', async () => {
        mockAxiosGetResult = {
          data: {
            name: `tasks/${todoTask.id}`,
            fields: {
              content: { stringValue: todoTask.content },
              status: { stringValue: todoTask.status }
            }
          }
        }
        action = 'createTask'
        await testedAction({ commit })
        expect(store.getters['todoTasks']).toContainEqual(todoTask)
      })
    })
  })
})

「ユーザーはフォームにタスクを入力して作成ボタンを押すと、ToDoタスク一覧に追加されることを確認できる」を実装する

タスク作成ボタンが押されるとaddTaskが呼び出されるように実装していきます。

addTaskメソッドはストアのcreateTaskを呼び出し、タスクが状態管理されるようにします。

・components/TaskForm.vue

addTaskから呼びだされるcreateTaskの実装をストアに書いていきます。

・store/index.js

import _ from 'lodash'

export const state = () => ({
  tasks: []
})

export const getters = {
  tasks: state => state.tasks,

...

}

export const mutations = {

  ...

  addTask(state, newTask) {
    state.tasks.push(newTask)
  }

...

}

export const actions = {
  async createTask({ commit }, payload) {
    const req = {
      fields: {
        content: {
          stringValue: payload.content
        },
        status: {
          stringValue: 'todo'
        }
      }
    }
    await this.$axios.post('/tasks', req, {
      baseURL: process.env._AXIOS_BASE_URL_
    }).then(res => {
      const newTask = {
        id: _.last(res.data.name.split('/')),
        content: res.data.fields.content.stringValue,
        status: res.data.fields.status.stringValue
      }
      commit('addTask', newTask)
    })
  }
 }

「ユーザーはフォームにタスクを入力して作成ボタンを押すと、ToDoタスク一覧に追加されることを確認できる」をテストする

実装が終わったら再度テストを流します。テストが全て通ればこのストーリーは完了です。

PASS  components/TaskForm.spec.js
  components/TaskForm.vue
    template
      ✓ タスク入力フォームが存在すること (11 ms)
      ✓ タスク作成ボタンが存在すること (6 ms)
      タスク入力がある場合
        ✓ dataに入力が反映されること (3 ms)
        ✓ タスク作成ボタンを押下するとaddTaskが呼ばれること (2 ms)
    script
      data
        ✓ dataの構造が正しいこと (1 ms)

PASS  store/index.spec.js
  store/index.js
    getters
      todoTasks
        ✓ statusがtodoのtaskが取得できること (3 ms)
      doneTasks
        ✓ statusがdoneのtaskが取得できること (1 ms)
      tasks
        ✓ すべてのtasksが取得できること (1 ms)
    actions
      fetchTasks
        ✓ tasksが取得できること (1 ms)
      createTask
        ✓ taskが追加されること (1 ms)

「ユーザーはフォームにタスクが入力していない場合は、作成ボタンを押すことができない」のテストを書く

フォームにタスクが入力していない場合は、作成ボタンを押すことができないことを確認できるテストを書いていきます。

・components/TaskForm.spec.js

import Vuex from 'vuex'
import { mount, createLocalVue } from '@vue/test-utils'
import * as store from '@/store'
import TaskForm from '@/components/TaskForm.vue'

const localVue = createLocalVue()
localVue.use(Vuex)

describe('components/TaskForm.vue', () => {
  let wrapper
  beforeEach(() => {
    wrapper = mount(TaskForm, {
      store: store,
      localVue
    })
  })


  describe('template', () => {

    ...

    describe('タスク入力がない場合', () => {
      beforeEach(() => {
        const mock = jest.fn()
        wrapper.vm.addTask = mock
        wrapper.find('input').setValue('')
      })

      test('dataに入力が反映されること', () => {
        expect(wrapper.vm.taskForm.content).toBe('')
      })

      test('タスク作成ボタンを押下するとaddTaskが呼ばれないこと', () => {
        wrapper.find('button').trigger('click')
        
        expect(wrapper.vm.addTask).not.toHaveBeenCalled()
      })
    })
  
  })

 ...

})

「ユーザーはフォームにタスクが入力していない場合は、作成ボタンを押すことができない」を実装する

ボタンにdisabled属性を付与し、computedでフォームの入力を監視してボタンの活性非活性を制御するように実装しました。

・components/TaskForm.vue

「ユーザーはフォームにタスクが入力していない場合は、作成ボタンを押すことができない」をテストする

実装が終わったら再度テストを流します。テストが全て通ればこのストーリーは完了です。

PASS  components/TaskForm.spec.js
  components/TaskForm.vue
    template
      ✓ タスク入力フォームが存在すること (9 ms)
      ✓ タスク作成ボタンが存在すること (1 ms)
      タスク入力がある場合
        ✓ dataに入力が反映されること (2 ms)
        ✓ タスク作成ボタンを押下するとaddTaskが呼ばれること (2 ms)
      タスク入力がない場合
        ✓ dataに入力が反映されること (1 ms)
        ✓ タスク作成ボタンを押下するとaddTaskが呼ばれないこと (1 ms)
    script
      data
        ✓ dataの構造が正しいこと (1 ms)

「ユーザーはToDoタスクの完了ボタンを押すと、完了タスク一覧にタスクが移動されることを確認できる」のテストを書く

ToDoタスクの完了ボタンを押すと、完了タスク一覧にタスクが移動されることを確認できるテストを書いていきます。

・components/TaskList.spec.js

import Vuex from 'vuex'
import { mount, createLocalVue } from '@vue/test-utils'
import * as indexStore from '@/store'
import TaskList from '@/components/TaskList.vue'

const localVue = createLocalVue()
localVue.use(Vuex)

describe('components/TaskList.vue', () => {
  let wrapper
  let store
  let todoTask
  let doneTask
  beforeEach(() => {
    store = new Vuex.Store(indexStore)
    todoTask = { id: '1', content: 'content_1', status: 'todo' }
    doneTask = { id: '2', content: 'content_2', status: 'done' }
    wrapper = mount(TaskList, {
      store: store,
      localVue
    })
    store.replaceState({ tasks: [todoTask, doneTask] })
  })

  describe('template', () => {
   
...

    describe('todoリストの完了をクリックする場合', () => {
      test('doneTaskが指定の引数で呼び出されること', () => {
        const mock = jest.fn(todoTask => todoTask)
        wrapper.vm.doneTask = mock
     
        wrapper.find('li.todo button').trigger('click')
        expect(wrapper.vm.doneTask).toHaveBeenCalled()
        expect(wrapper.vm.doneTask.mock.results[0].value).toBe(todoTask)
      })
    })
  })

  ...

})

ストアではタスクのステータスが更新されることが確認できるテストを書いていきます。

・store/index.spec.js

import Vuex from 'vuex'
import * as index from '@/store'
import { createLocalVue } from '@vue/test-utils'
import _ from 'lodash'
import axios from 'axios'

const localVue = createLocalVue()
localVue.use(Vuex)

let mockAxiosGetResult
jest.mock('axios', () => ({
  
...

  patch: jest.fn(() => Promise.resolve(mockAxiosGetResult))
}))

let action
const testedAction = (context = {}, payload = {}) => {
  return index.actions[action].bind({ $axios: axios })(context, payload)
}

describe('store/index.js', () => {
  let store
  let todoTask, doneTask
  beforeEach(() => {
    store = new Vuex.Store(_.cloneDeep(index))
    todoTask = { id: '1', content: 'content_1', status: 'todo' }
    doneTask = { id: '2', content: 'content_2', status: 'done' }
  })


...

  describe('actions', () => {
    let commit
    beforeEach(() => {
      commit = store.commit
    })

   ...

    describe('updateTask', () => {
      beforeEach(() => {
        store.replaceState({
          tasks: [todoTask]
        })
      })

      test('taskが更新されること', async () => {
        mockAxiosGetResult = {
          data: {
            name: `tasks/${todoTask.id}`,
            fields: {
              content: { stringValue: 'updatedContent' },
              status: { stringValue: 'done' }
            }
          }
        }
        action = 'updateTask'
        await testedAction({ commit })
        expect(store.getters['doneTasks']).toContainEqual({
          id: todoTask.id,
          content: 'updatedContent',
          status: 'done'
        })
      })
    })
  })
})

「ユーザーはToDoタスクの完了ボタンを押すと、完了タスク一覧にタスクが移動されることを確認できる」を実装する

ToDoタスクの完了ボタンを押すと、ストアのupdateTaskを呼び出しステータスを完了にすることで完了タスク一覧に移動されるように実装します。

・components/TaskList.vue

・store/index.js

import _ from 'lodash'

export const state = () => ({
  tasks: []
})

export const getters = {
  tasks: state => state.tasks,

  ...

}

export const mutations = {
  
...

  updateTask(state, newTask) {
    const task = state.tasks.find(task => task.id === newTask.id)
    if (task) {
      task.content = newTask.content
      task.status = newTask.status
    }
  }
}

export const actions = {
 
...

  async updateTask({ commit }, payload) {
    const req = {
      fields: {
        content: {
          stringValue: payload.content
        },
        status: {
          stringValue: payload.status
        }
      }
    }
    await this.$axios.patch(`/tasks/${payload.id}`, req, {
      baseURL: process.env._AXIOS_BASE_URL_
    }).then(res => {
      const updateTask = {
        id: _.last(res.data.name.split('/')),
        content: res.data.fields.content.stringValue,
        status: res.data.fields.status.stringValue
      }
      commit('updateTask', updateTask)
    })
  }
}

「ユーザーはToDoタスクの完了ボタンを押すと、完了タスク一覧にタスクが移動されることを確認できる」のテストをする

実装が終わったら再度テストを流します。テストが全て通ればこのストーリーは完了です。

PASS  components/TaskList.spec.js
  components/TaskList.vue
    template
      ✓ todoリストが表示されること (17 ms)
      ✓ 完了リストが表示されること (2 ms)
      todoリストの完了をクリックする場合
        ✓ doneTaskが指定の引数で呼び出されること (3 ms)
    script
      computed
        todos
          ✓ storeからtodoTasksが取得できること (1 ms)
          ✓ storeからdoneTasksが取得できること (2 ms)

PASS  store/index.spec.js
  store/index.js
    getters
      todoTasks
        ✓ statusがtodoのtaskが取得できること (3 ms)
      doneTasks
        ✓ statusがdoneのtaskが取得できること (1 ms)
      tasks
        ✓ すべてのtasksが取得できること
    actions
      fetchTasks
        ✓ tasksが取得できること (1 ms)
      createTask
        ✓ taskが追加されること
      updateTask
        ✓ taskが更新されること

「ユーザーは完了タスクのToDoに戻すボタンを押すと、ToDoタスク一覧にタスクが移動されることを確認できる」のテストを書く

完了タスクのToDoに戻すボタンを押すと、ToDoタスク一覧にタスクが移動されることを確認できることが確認できるテストを書いていきます。

ストアのタスクステータス更新のテストは先程のストーリーで確認済みなため、新しくストアのテストは書いていません。

・components/TaskList.spec.js

import Vuex from 'vuex'
import { mount, createLocalVue } from '@vue/test-utils'
import * as indexStore from '@/store'
import TaskList from '@/components/TaskList.vue'

const localVue = createLocalVue()
localVue.use(Vuex)

describe('components/TaskList.vue', () => {
  let wrapper
  let store
  let todoTask
  let doneTask
  beforeEach(() => {
    store = new Vuex.Store(indexStore)
    todoTask = { id: '1', content: 'content_1', status: 'todo' }
    doneTask = { id: '2', content: 'content_2', status: 'done' }
    wrapper = mount(TaskList, {
      store: store,
      localVue
    })
    store.replaceState({ tasks: [todoTask, doneTask] })
  })

  describe('template', () => {
   
...

   describe('完了リストのToDoに戻すをクリックする場合', () => {
      test('returnTaskが指定の引数で呼び出されること', () => {
        const mock = jest.fn(doneTask => doneTask)
        wrapper.vm.returnTask = mock
     
        wrapper.find('li.done button').trigger('click')
        expect(wrapper.vm.returnTask).toHaveBeenCalled()
        expect(wrapper.vm.returnTask.mock.results[0].value).toBe(doneTask)
      })
    })
 })

  ...

})

「ユーザーは完了タスクのToDoに戻すボタンを押すと、ToDoタスク一覧にタスクが移動されることを確認できる」を実装する

完了タスクのToDoに戻すボタンを押すと、ストアのupdateTaskを呼び出しステータスをToDoにすることでToDoタスク一覧に移動されるように実装します。

・components/TaskList.vue

「ユーザーは完了タスクのToDoに戻すボタンを押すと、ToDoタスク一覧にタスクが移動されることを確認できる」のテストをする

実装が終わったら再度テストを流します。テストが全て通ればこのストーリーは完了です。

PASS  components/TaskList.spec.js
  components/TaskList.vue
    template
      ✓ todoリストが表示されること (12 ms)
      ✓ 完了リストが表示されること (3 ms)
      todoリストの完了をクリックする場合
        ✓ doneTaskが指定の引数で呼び出されること (3 ms)
      完了リストのToDoに戻すをクリックする場合
        ✓ returnTaskが指定の引数で呼び出されること (2 ms)
    script
      computed
        todos
          ✓ storeからtodoTasksが取得できること (1 ms)
          ✓ storeからdoneTasksが取得できること (5 ms)

全部のテストを流す

全部の実装が終わったら、全てのテストを流します。package.jsonのscriptに”test”: “jest –config jest.config.js”を追加し、以下のコマンドで実行します。

$ npm run test

PASS components/TaskForm.spec.js
PASS components/TaskList.spec.js
PASS store/index.spec.js

全てのテストが通ったら完了です。

The post 【Nuxt.js】JestでTDDを実践してみる first appeared on みんたく.