SwapBuilding A Master-Detail Screen The Server-Driven Way
Master-detail screens are one of the best tests for a server-driven UI approach.
They need to feel responsive. The selected row should update the detail pane quickly. Related badges or metadata may need to change too. At the same time, the screen should remain understandable, navigable, and linkable.
That is exactly the kind of screen where clear responsibilities matter more than client-side cleverness.
Start with two honest regions
At minimum, the screen usually has two responsibilities:
- the master list,
- the detail panel.
Treat them that way in the markup and in your response logic. If selection changes should update both, model that directly instead of pretending the screen has only one meaningful target.
Keep selection state explicit
The selected item is state. Do not let it become an invisible browser-side assumption.
If a detail view matters enough to inspect, it usually matters enough to have a real route or parameter that represents it. That keeps refresh behavior, bookmarking, and history far cleaner.
This is where SwapState and sensible route design complement each other.
Update the screen by workflow
When the user changes selection, ask what should actually move:
- only the detail panel,
- the detail panel plus a summary,
- maybe the selected-row styling in the list as well.
If several regions are affected, SwapResponse() is a better fit than pretending the detail panel is the only thing that changed.
Avoid over-rendering
It is tempting to refresh the whole screen because it is simple. That works until the page grows and performance or flicker becomes noticeable.
A better rule is to refresh the smallest set of regions that fully represent the new state. That keeps the UI fast without making the controller logic obscure.