Model the state, not the screen

A state shape that mirrors the screen, a field per panel, a flag per visible section, an array in the order the list happens to render, locks the data to one design. Move the panel and you migrate the store. Add a second view of the same thing and you duplicate the data, then spend a fortnight keeping the copies in sync.

The alternative is to model what is true regardless of display. A task has an id, a title, a status and an assignee. Whether the board groups by status or the list sorts by assignee is a rendering question, answered by a function over that data. Sorting and grouping are cheap; keeping two sources of truth agreed is not.

The test to apply is simple. For each field, ask what real-world fact it records. If the honest answer is "the accordion is open", it is UI state and belongs near the component. If it is "the invoice was paid on Tuesday", it belongs in the model. Mixing them is what makes state hard to reason about, and separating them is most of what people mean when they say a codebase is well structured.