One script per page, cleanly cut – learn C# (K2, lesson 16)

What you learn in this lesson

cut a page script into small functions with one job each

pass elements, address and fetch in as parameters instead of grabbing them in the middle of the logic

put rules without the DOM in a module of their own and load it with import

leave no changeable state at the top of the module and wire everything in one init

load data with fetch and handle error statuses, wrong responses and a time limit with AbortController

check a response as unknown, even when an API hands back any

report an error in a way that keeps the page usable

The instant filter from lesson 2.2.3 works. Now the contact list is supposed to do one more thing: A “Refresh list” button fetches the contacts from the server again without reloading the page, and the search text and the focus stay where they are. Your colleague has already built it, in a version of the script of her own, a good hundred lines in one piece. It runs on her machine.

Before something like that goes into the Kladde, a second look is worthwhile. In this lesson you learn how to recognize a well-cut page script, and how to load data so that a slow or broken server doesn’t drag the page down with it. In the end, the Kladde’s filter script is a module with a single init, and it loads the list with a time limit and an understandable message when something goes wrong.

One script per page

The Kladde’s house rules allow at most one script per page. What that means is one <script type="module"> in the HTML. That module may load other modules, with import. For the page, it’s still one entry point, and whoever wants to know what happens on the contact list starts in contacts.ts. Several scripts side by side, on the other hand, don’t know each other. Each one looks for its own elements, two attach themselves to the same event, and which one runs first is written down nowhere.

What you learn in this lesson

One script per page

This lesson belongs to course K2