04-code-organization/04-reusable-sections-with-paths.md

Reusable sections with paths

Some sections are reused multiple times while still reading from and writing to store state.

In these cases, a section may accept a scoped path or equivalent selector inputs so the same section logic can operate on different parts of feature state without duplicating code.

When to use this pattern

Use a reusable section with a provided path when:

the same store-aware UI structure appears multiple times
each instance works on a different state location
reusing the section is clearer than duplicating the same orchestration
the path or scope keeps ownership explicit

Examples:

repeated form subsection editors
repeated settings groups
repeated nested item editors

What inputs to prefer

Prefer explicit scoped inputs such as:

path
scopeId
selector arguments
feature-local read/write helpers

The goal is to keep the section reusable while still making the state boundary obvious.

What to avoid

Avoid this pattern when:

the section is only used once
passing a path would make the code harder to understand
a plain component with props would be simpler
the section becomes too generic and loses feature meaning

Design rules

A reusable section with a path should:

keep one clear UI responsibility
make the scoped state obvious
use consistent naming for scoped inputs
avoid hidden coupling to unrelated state

Final rule

Use reusable store-aware sections with scoped paths only when they remove real duplication without making ownership harder to understand.