riverpod-select

Watch only a subset of Riverpod state with provider.select to reduce widget rebuilds.

Updated Mar 28, 2026
One-click install
npx skills add https://github.com/masssi164/weave --skill riverpod-select-masssi164
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: riverpod-select
Source: https://github.com/masssi164/weave/tree/main/.agent/skills/riverpod-select
Command: npx skills add https://github.com/masssi164/weave --skill riverpod-select-masssi164

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

ref.watch(provider) can trigger rebuilds whenever the provider's value changes, even if only a subset of the state is used.

Core Features & Use Cases

  • Selective watching: watch only a subset of the state via provider.select(...)
  • Performance gains: reduce unnecessary widget rebuilds
  • Async provider support: use selectAsync for async providers when available; ensure immutability of selected values

Quick Start

Watch only a subset by using provider.select in your ref.watch call to rebuild only when the selected field changes.

Frequently Asked Questions about riverpod-select

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reduce widget rebuilds in Riverpod when only a single field changes?

To reduce widget rebuilds in Riverpod, use ref.watch(provider.select(...)) to watch only the specific subset of state your widget needs, triggering rebuilds exclusively when that selected field changes.

Why does my Flutter widget rebuild unnecessarily with Riverpod state management?

Your Flutter widget rebuilds unnecessarily because standard ref.watch(provider) triggers rebuilds whenever any part of the provider's value changes, even if your widget only depends on a single field of a large object.

Can I use Riverpod select with async providers?

Yes, you can use selectAsync for async providers when available to watch subsets of state, ensuring that the selected value remains immutable to guarantee correct rebuild behavior.

When should I use select with Riverpod instead of watching the entire provider?

You should use Riverpod's select when a widget depends on a single field of a large object or when performance is degraded by frequent rebuilds caused by frequent state changes.

What are the limitations of using Riverpod select for state management?

A key limitation is that the selected value must be immutable; if the selected subset of state is mutable, Riverpod's select mechanism will fail to correctly detect changes and trigger necessary widget rebuilds.