Controllers

A controller connects the pure pieces

Our controller receives search and render dependencies. It owns state, a generation counter, the active AbortController, and a disposed flag. Its load method cleans the query, invalidates older work, starts a request, decodes the returned books, and sends a transition only if the attempt is still current.

A small send(action) helper updates state with the reducer and calls render. Keeping those together avoids a state update that forgets to refresh the interface. The optional initial saved array must already satisfy the book contract; decode restored storage before passing it. The renderer must treat state as read-only; getState returns the current snapshot by convention, not a frozen deep copy.

There are two guards after asynchronous work: disposed prevents updating a departed view, and mine !== generation prevents an older attempt from replacing a newer one. The error path needs the same checks. Cancel invalidates the generation before aborting, so an abort rejection is stale and does not become a service error on the screen.

Read the smaller controller below before opening the full project. It deliberately omits cancellation and schema validation to isolate the ownership rule; the downloadable controller includes them. The dependencies make it possible to test this flow with no DOM and no timer sleeps.

Predict and trace

Write the output before running. Follow the values through each call; if your prediction differs, identify the first step that surprised you.

async function main() {
  function createLoader(search, render) {
    let generation = 0;

    return async function load(query) {
      const mine = ++generation;

      render("loading");

      try {
        const value = await search(query);

        if (mine === generation) {
          render(value);
        }
      } catch (error) {
        if (mine === generation) {
          render(error.message);
        }
      }
    };
  }

  const messages = [];
  const load = createLoader(
    async () => "ready",
    text => messages.push(text)
  );

  await load("web");
  console.log(messages.join(", "));
}

main();

loading, ready

Run the actual controller without a webpage

The console lab below combines the same controller.js and model.js used by the final app inside an async main entry point. The short entry code at the top supplies a controlled search function and a renderer that prints status. The first load returns a valid book; the second returns a wrong-type title. Predict the sequence, then follow each status to its reducer action.

loading
ready
Notes
loading
error
Each book needs an id and title

This single-program lab puts its entry code first, followed by the function definitions. Function declarations using function can be called earlier in the same scope; this is called hoisting. You do not have to organize your own code this way. The lab preserves the short, editable entry at the top while keeping the actual core functions available below it.

The console lab combines files because this editor’s file-tab mode does not support top-level await. The synchronous module example on Day 2 is unaffected; the downloaded project uses ordinary ES modules and runs controller-demo.js with Node. You do not need to install anything to practise here.

On your first pass, trace one successful load from the entry code, then trace the invalid response. You do not need to transcribe the combined definitions: the goal is to recognize where each earlier lesson participates.

Read the program in this order:

1. In the entry code at the top, find the injected search and render dependencies.
2. In createController below it (from controller.js), follow load from the loading action through search, decoding, and the current-generation check. async load(text) { ... } is an async method stored under load. active?.abort() calls abort only when an active controller exists.
3. In the model functions (from model.js), find which fields each action changes and which saved fields it preserves.
4. Return to the entry code, change the second title from 42 to a string, and predict which error output disappears. Run again.

This is the final app’s data flow before adding HTML. Keep the smaller sketch above as a way to isolate ownership, not as a replacement missing the full controller’s guards. In the downloaded project, node controller-demo.js runs this same console entry point.

Build it yourself

// Await the operation inside try/catch.

async function main() {
  async function attempt(load, report) {
    report("loading");

    try {
      await load();
      report("ready");
    } catch {
      report("error");
    }
  }

  const statuses = [];

  await attempt(
    async () => {
      throw new Error("offline");
    },
    status => statuses.push(status)
  );
  console.log(statuses.join(", "));
}

main();

loading, error

Test a changed requirement

Try a loader returning []. Then explain exactly where generation checks must be added before reusing this function for overlapping searches.

Explain before moving on

Why must cancel invalidate before abort? What would an unconditional render in finally break?