EODHD Academy
‹ Build a Screener Lesson 8 of 17
Contents Lesson 8 of 17

4 min read · practitioner

Saved screens — the criteria you keep coming back to

Retyping four filters every morning is how a tool stops getting used. This lesson makes a screen a thing you name and reopen.

What a saved screen is

A name and a set of filters. Nothing else — and specifically not the results:

type SavedScreen = {
  name: string;
  filters: Filter[];
  sort: string;
  createdAt: string;
};

Saving results would freeze a snapshot of yesterday and quietly show it to you tomorrow. Saving criteria means reopening asks the market again. The whole value of a screen is that its answer changes.

Where it lives, and the same three rules

Browser storage, exactly like your notes in course 1, and for the same reasons: personal, changes often, no server needed. And the same three rules apply, which is a good sign that you learned something general:

  • Version the key (screens-v1), so a shape change does not break the tool for anyone who used the last one.
  • Guard the parse with try/catch, because half a write from a crashed tab throws and takes the page down.
  • Key by name, not index, so reordering does not silently rename people's screens.

Noticing that these are the same three rules is the point. That is what "transferable" means in practice.

The URL is the other place a screen can live

Worth considering, and cheap: encode the current filters into the query string. Then a screen is shareable, bookmarkable, and survives you clearing storage — and the back button starts working the way people expect.

/screener?f=market_capitalization:gt:1000000000,dividend_yield:gt:0.02

It also creates one obligation. Anything in a URL is input from a stranger, because someone can send you a link. Everything from lesson 3 applies to it: validate against the allowlist, drop what does not pass, never trust the string.

Say when the results are from

A saved screen reopened tomorrow runs against tomorrow's data — good. But recall from lesson 3 that last_day_data_date was 2026-08-24 on a screen run on the 25th. A screen is always at least one session behind, and that must be visible next to the results rather than assumed.

This is the same discipline as the data-age panel in course 1, applied to a different surface. It is also what makes the breadth wall in unit 4 an observation instead of a claim.

Try it now

Save two screens you would genuinely use, close the tab, reopen and run one. Then take the URL of a screen, edit the filters in the address bar by hand to something absurd, and load it. What happens next tells you whether lesson 3's allowlist is real or whether you only validated the form.