本文へ移動
cccskills
無料GitHub で公開

api-client-integration

Use when a component talks to the backend - go through the typed api client, type every response, and handle loading, success, and error states explicitly

インストール方法を見る

含まれるファイル(1)

  • SKILL.md2.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

API Client Integration

Overview

Every remote call is three states, not one. The recurring defects are raw fetch scattered in components, untyped responses, and errors swallowed into console.log while the UI half-updates.

Core principle: One typed client, three states (loading/success/error), no swallowed errors.

Rules

  • Go through web/src/api.ts helpers — never raw fetch in components.
  • Type every response with an interface matching the backend JSON. A contract change starts by updating the interface so the compiler finds every affected usage.
  • Handle all three states: loading (visible feedback), success, and error (toast with an actionable message).
  • Never swallow errors into console.log — surface them to the user and keep the UI consistent (no half-updated state on failure).
  • Debounce user-driven queries; cancel or ignore stale responses when inputs change quickly.

Worked Example

// ✅ typed client call, three states, no half-update on failure
const [state, setState] = useState<Loadable<Task[]>>({ status: "loading" });

useEffect(() => {
  let active = true;
  api.listTasks(projectId)                       // typed helper from api.ts
    .then(tasks => active && setState({ status: "ok", data: tasks }))
    .catch(err => active && setState({ status: "error", message: err.message }));
  return () => { active = false; };              // ignore stale response
}, [projectId]);

if (state.status === "loading") return <Spinner />;
if (state.status === "error") return <ErrorView message={state.message} />;
return <TaskList tasks={state.data} />;          // success only

The active flag drops a stale response when projectId changes; the error branch shows a real message instead of leaving a spinner or a half-list.

Common Mistakes

  • Raw fetch in a component.
  • Untyped/any response.
  • Only rendering the success path — no loading/error.
  • catch(e => console.log(e)) with the UI left inconsistent.
  • No stale-response guard on fast-changing inputs.

Red Flags

  • fetch( inside a component file.
  • A remote call with no error UI.
  • A toast that says "error" with no actionable message.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月10日 更新

Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月10日 更新

Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月10日 更新

Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月10日 更新

How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月10日 更新

Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月10日 更新

makifbaysal のスキルをすべて見る

このスキルの問題を報告する