Three tools, one product — what composition costs
You have three working things: a watchlist, a screener, a backtester. This course puts them on one surface, where three tools sharing a page stop being three tools.
What breaks the moment they share a screen
Each tool was built assuming it owned everything: its own fetch, its own storage key, its own idea of what "selected" means. Put them side by side and four assumptions collide.
Two panels want the same quote. The watchlist has AAPL and so does the screener result. Fetched independently, that is two requests for one fact — and since /real-time is billed per symbol, two calls.
Two panels disagree about the same instrument. One took its price at 20:28, the other at 20:29. Both are correct and the page is inconsistent, which is worse than either being wrong.
"Selected" means three things. Selected-in-watchlist, selected-in-screener and being-backtested were separate concepts. On one surface a person expects clicking a row to mean something everywhere.
Storage keys multiply. Three tools, three localStorage keys, three shapes, and no migration path when one changes.
None of these is a bug in any tool. They are the cost of composition, and the whole course is about paying it deliberately.
The discipline: architecture and state
Courses 1 to 3 gave you planning, review and testing. This one gives you the question those three cannot answer: where does each piece of state live, and who is allowed to change it?
Three places, and picking wrongly is what makes a dashboard unmaintainable:
- Panel-local. Which column is sorted, whether a section is collapsed. Nobody else cares, so nobody else should see it.
- Shared. The selected instrument, the date range, the cached quote for a symbol. More than one panel reads it, so exactly one thing owns it.
- Persisted. Your watchlist, your saved screens, your layout. It must survive a reload, and that is unit 1's second half.
The failure mode is putting shared state in a panel. It works, then a second panel needs it, so it gets passed down through three components, and eventually somebody caches a copy. That copy is the bug you will spend a Saturday on.
Rebuild the whole, not the parts
This is course 2's discipline at a larger scale. The four questions again — what survives, what generalises, what is new, what dies — applied to three products at once.
Survives: the proxy, the transport layer, the error handling, the CI key scan. All of it, untouched.
Generalises: the table component you already generalised once. Now it has a third caller, which is when you find out whether the abstraction was right.
New: a layout, a shared store, an alert evaluator.
Dies: three separate page shells, and any code that assumed a tool owned the whole screen.
What you will have at the end
One page with configurable panels, layouts you can name and restore, alert rules that survive a reload, and a refresh budget you can defend — plus a wall you will hit that the previous three courses only pointed at.
The finance behind it
A cockpit exists to answer a question; the benchmark lesson is where that discipline comes from: What is a benchmark actually for?
Try it now
Before writing anything, list every piece of state in your three tools and mark each one panel-local, shared or persisted. The list will be longer than you expect, and the shared row is the design of this whole course.