We’ve explored how resource() handles loading, cancellation, and all six status states. But there’s one pattern left that separates a good app from a great one: optimistic updates.

Most applications handle two data states: “loading” and “loaded.” Maybe three if they remember errors. But in a real enterprise dashboard, there are six distinct states — and handling each explicitly is the difference between a polished product and a buggy one.

In the previous post, we declared our resource() with a params computation and a loader. The user types a query, and the resource fetches matching projects.

Welcome to Phase 3B — the deepest technical dive in our series so far. In Phase 3A, we pre-fetched data using resolvers. But resolvers are a routing tool. What about data that depends on user interaction — a search query, a filter, a date picker?

We’ve built the data pipeline (Part 1) and the dashboard UI (Part 2). The app works. But “works” and “feels amazing” are two very different things.

In the previous post, our resolver pre-fetched the dashboard data and handed it to the Router. But how does the component actually receive it?

Welcome to Phase 3A — where our dashboard stops being a static shell and starts becoming intelligent. In Phase 2 we secured the routes and built the layout. Now we need to fill it with data.