Vue — 非同期 UX 3 状態

Vue — 非同期 UX 3 状態

api / ch01

このチャプターの到達ゴール

目的 (= 3 状態を必ず見せる)

API 通信は 必ず失敗する (= ネット切れ / API 落ち / バリデーション失敗 / レート制限)。

ユーザーに「今どうなっているか」 を見せるのが UX の最低限。

> 3 状態のうち 失敗を最初から考える のが プロのコード。 成功パスしか書かない人は事故る。

store に loading / error 状態を持つ

export const useTasksStore = defineStore('tasks', () => {
  const tasks   = ref([])
  const loading = ref(false)            // ← 追加
  const error   = ref('')               // ← 追加

  async function load() {
    loading.value = true
    error.value = ''
    try {
      const res = await fetch('http://localhost:8000/tasks')
      if (!res.ok) throw new Error(`HTTP ${res.status}`)
      tasks.value = await res.json()
    } catch (e) {
      error.value = `読み込みに失敗しました: ${e.message}`
    } finally {
      loading.value = false             // ← try でも catch でも必ず通る
    }
  }
  // ...
})

なぜ finally が要るのか

仮に finally を忘れて こう書くと、 エラー時にスピナーが回り続ける:

async function load() {
  loading.value = true
  try {
    const res = await fetch('...')
    tasks.value = await res.json()
    loading.value = false                // ← 成功時しか通らない
  } catch (e) {
    error.value = '失敗しました'
    // loading.value = false を忘れがち
  }
}

finally は try でも catch でも必ず通る ブロック。

「成功でも失敗でも 必ずやること」 (= スピナーを止める / リソースを閉じる) はここに書く。

> これは Pinia 固有ではなく try/catch/finally の基本。 Vue/Pinia の外でも毎日使う。

view 側でローディング表示

<script setup>
import { onMounted } from 'vue'
import { storeToRefs } from 'pinia'
import { useTasksStore } from '@/stores/tasks'

const store = useTasksStore()
const { tasks, loading, error } = storeToRefs(store)

onMounted(() => store.load())
</script>

<template>
  <h1>タスク一覧</h1>
  <p v-if="loading">読み込み中...</p>
  <p v-else-if="error" class="err">
    {{ error }}
    <button @click="store.load()">再読み込み</button>
  </p>
  <ul v-else>
    <li v-for="t in tasks" :key="t.id">{{ t.name }}</li>
  </ul>
</template>

v-if / v-else-if / v-else の順序が肝

> 「ローディングのまま中身が見える」 と 「エラーなのに古いデータが見える」 はよくある UX バグ。

> 排他的に v-if/v-else で繋ぐ ことで防げる。

フォーム送信の二重送信防止

// forms/ch01 で書いた onSubmit に submitting / errorMsg を足す
const submitting = ref(false)
const errorMsg   = ref('')

async function onSubmit() {
  touched.value = true
  if (!isValid.value || submitting.value) return       // ← 多重クリック防止
  submitting.value = true
  errorMsg.value = ''
  try {
    await store.add(name.value.trim())
    router.push('/')
  } catch (e) {
    errorMsg.value = `追加できませんでした: ${e.message}`
  } finally {
    submitting.value = false
  }
}

ボタンラベル切替 + エラー表示

<template>
  <input v-model="name" @blur="touched = true" />
  <p class="warn">{{ errorMessage }}</p>

  <button :disabled="!isValid || submitting" @click="onSubmit">
    {{ submitting ? '追加中...' : '追加' }}
  </button>
  <p v-if="errorMsg" class="err">{{ errorMsg }}</p>
</template>

> ボタンラベルが変わる = ユーザーが「処理中だ」 と認識できる。 これも 3 状態のうちの 1 つ。

store の add も try/catch 化

async function add(name) {
  if (!name || !name.trim()) throw new Error('空の名前は登録できません')

  const res = await fetch('http://localhost:8000/tasks', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ name: name.trim() }),
  })
  if (!res.ok) {
    const body = await res.text()
    throw new Error(`API エラー: HTTP ${res.status} ${body}`)
  }
  const created = await res.json()
  tasks.value.push(created)
}

> store 内で throw すれば、 呼び出し側 (view) の try/catch でメッセージ化できる。

> store と view で責務を分けるのが良い書き方。

わざと壊して確認 (= 3 状態を体に入れる)

> ⚠️ エラー UI は わざと壊して見る のが大事。 開発中に通常系しか見ない人が多い。

チャプター完了サイン

• [ ] 起動直後に 「読み込み中…」 が一瞬見える
• [ ] API を止めると エラーメッセージ + 再読み込みボタン が出る
• [ ] 「追加」 ボタンが連打防止になっている (= 連打しても 1 度しか POST されない)
• [ ] 「追加中…」 表示が押下後に出る
• [ ] 「なぜ finally が要るのか」 を 1 文で言える

次に学ぶ領域

> 全部覚える必要はない。 「今日の try/catch/finally がライブラリの中で同じことをしている」 という地図だけ持っておく。