home / skills / forge-town / skills / use-store-not-props-best-practice

use-store-not-props-best-practice skill

safe

/skills/use-store-not-props-best-practice

This skill analyzes components and rewrites them to fetch data directly from the store, reducing prop usage and enhancing maintainability.

npx playbooks add skill forge-town/skills --skill use-store-not-props-best-practice

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

870 B

---
name: use-store-not-props-best-practice
description: 查看给出的组件并进行修改，尽可能的不要使用props，尽可能直接从store中获取数据。
---

# 使用 Store 而非 Props 最佳实践

此最佳实践的核心原则是：

1. **查看给出的组件并进行修改**：分析现有组件的代码结构
2. **尽可能的不要使用props**：减少或避免通过 props 传递数据
3. **尽可能直接从store中获取数据**：优先使用全局状态管理库直接访问数据

## 工作原理

- 检查组件是否通过 props 接收数据
- 确认所需数据是否在全局 store 中可用
- 重构组件以直接从 store 获取数据，移除不必要的 props

## 使用方法

在重构组件时应用此原则：优先检查 store 数据可用性，然后修改组件代码以直接访问 store 而非依赖 props 传递。

Overview

This skill inspects components and refactors them to prefer store-based data access instead of props. It analyzes component code, identifies props that can be replaced by store reads, and produces modified TypeScript components. The goal is to simplify component APIs and centralize state access for maintainability.

How this skill works

The skill scans the provided component source to detect props declarations and usages. It checks the global store shape (Redux, Zustand, Pinia, etc.) or a supplied state module to see if the same data exists there. When possible, it rewrites the component to import and read from the store directly and removes redundant props and prop typings. The output includes the updated component code and a brief changelog of removed props and new store hooks/imports.

When to use it

Refactoring legacy components that receive many props from parent chains.
Reducing prop drilling across nested component trees.
Centralizing state access when a global store already contains the same data.
Preparing components for a feature that relies on a shared store snapshot.
Improving component API clarity by removing redundant external inputs.

Best practices

Prefer store reads for data that is truly global or shared across many components.
Keep component-specific state as local state; do not move ephemeral UI state into the store unnecessarily.
Remove only props that have a verified equivalent in the store to avoid breaking behavior.
Update type definitions to reflect removed props and new store-derived values.
Add unit tests or integration tests verifying behavior after refactor to catch regressions.

Example use cases

Convert a presentational component that receives user profile via props to read currentUser from the auth store.
Simplify deeply nested children that only used a theme or locale prop by reading theme/locale from the global store.
Refactor list components that accept data arrays via props to obtain the array from a centralized cache store.
Replace a prop-driven loading flag with a store selector when loading is managed globally.
Batch-remove multiple props that duplicate values already stored in a feature module.

FAQ

Will this break components that rely on injected props for testability?

You should update tests to mock the store or provide a test store. If a prop is only used for testing, consider keeping it or creating a configurable store provider for tests.

Which stores are supported?

The skill targets common patterns (Redux selectors, Zustand hooks, Vuex/Pinia accessors) and generic module exports. If a custom store API is used, provide the access pattern or adapter.

How do you handle prop types and TypeScript interfaces?

The refactor updates component props interfaces to remove replaced fields and adds types for store-derived values. It preserves remaining prop typings and reports the changes.