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

routing-state

Use when adding routes or deciding where state lives - carry resource ids and navigation-surviving state in the URL, keep route components thin, and lift shared state to a hook not a global store

インストール方法を見る

含まれるファイル(1)

  • SKILL.md2.0 KB

SKILL.md(原文)

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

Routing & State

Overview

Where state lives decides whether a view is deep-linkable and refresh-safe. The recurring defects are navigation-surviving state (a selected tab, a filter) trapped in component state that resets on refresh, and fat route components.

Core principle: If it should survive a refresh or be shareable by URL, it lives in the URL.

Rules

  • react-router-dom for navigation; URL params carry resource ids so views are deep-linkable and refresh-safe.
  • State that survives navigation (filters, selected tab, search) lives in the URL search params — not component state.
  • Lift shared state into a custom hook when multiple pages need it; avoid a global store for what two components can share via props.
  • Route components stay thin: data loading + layout only; behavior lives in child components and hooks.

Worked Example

// ❌ selected filter lost on refresh, not shareable
const [status, setStatus] = useState("all");

// ✅ filter in the URL — refresh-safe, shareable, back-button works
const [params, setParams] = useSearchParams();
const status = params.get("status") ?? "all";
const setStatus = (s: string) => setParams(prev => { prev.set("status", s); return prev; });

Now /board?status=in_progress deep-links to the filtered view and survives a refresh.

Common Mistakes

  • A filter/tab in useState that resets on refresh and can't be shared.
  • A global store for state two sibling components could pass via props.
  • A route component packed with behavior instead of delegating to children/hooks.

Red Flags

  • A shareable view state that isn't in the URL.
  • A new global store for a two-component concern.
  • A route component you scroll to read.

レビュー

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

同じリポジトリのスキル

概要と使いどころ

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月11日 更新

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月11日 更新

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月11日 更新

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月11日 更新

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月11日 更新

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月11日 更新

makifbaysal のスキルをすべて見る

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