yatta/binding

Binds one call to a store.

`start` is separate because a binding is built during a render, and a render must not do work — that is what makes it safe to render many times, and what stops a Server Component from multiplying requests.

store

Where results live. Per request on a server, shared in a browser.

method

The route's method, taken from the app.

args

Its arguments. Part of the key, so different arguments never share.

The key one call is stored under: its route and its arguments.

Shares one framework subscription across many subscribers.

Written this way because the alternative — one subscription per component — is a subscription per component on the same store, which is what a framework charges for.

track

Starts the framework subscription and returns its teardown.

The route a method came from, used as the key's prefix.

The derived methods are named after their routes, so this is the route name. Two routes cannot collide under one key — which matters, because a key built from arguments alone would let one route serve another's cached value.

Whether two states are indistinguishable to a reader.

Compared field by field, because the store hands out a fresh object on every write: an identity check would report a change on every notification and defeat the whole point of the filter above.

A binding that never notifies: correct on a server, where nothing updates.

Serialises arguments so key order does not matter.

`{ id: "1", q: 2 }` and `{ q: 2, id: "1" }` are the same call. Keying them differently makes a component refetch whenever its parent reorders a literal. The non-plain cases are handled explicitly, because `Object.entries` sees them as empty and every one of them silently becomes `"{}"`: - A `Date` has no own enumerable properties, so two *different* dates produced the same key. Every date-range query then shared one cache entry and returned whichever date happened to be cached first. - A `RegExp` and a `Map` or `Set` have the same problem. - A circular structure recursed until the stack overflowed, which took down the render that built the arguments. `undefined` and `{}` are the same call, so an omitted argument does not fork the key.

Subscribes to one call's changes.

The one thing every framework binding does. Returns the current state immediately, so a subscriber never renders one frame against an empty cache. Filtered to the key, and gated on the state actually having changed. Without either, the store's subscribe is global: one mutation anywhere woke every mounted component, each allocated a fresh state object, and each re-rendered. On a page with fifty calls that is fifty renders to change one, and the reason a small change could be felt as a janky one.

How a binding is told the store changed.

One operation: register a callback and get back an unsubscribe.

A bound call.

Reads through to the store, so `state` is correct whether or not a notification has arrived yet.