Use global stores sparingly

Start from the behavior you can observe. A global connection status may belong in a store; one issue row’s menu state does not.

A store expands who can read and mutate a value, so it should represent page-wide state with a clear mutation model. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to move state to a store merely because two expressions reference it. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to identify the true owners and mutations before promoting state beyond component scope. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Extract reuse only where it clarifies the board, keeping local components local and global state rare. Record enough evidence that another developer can repeat the result without relying on your memory.

Audit every state value on the board and justify the few that need to be global. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.