Function createCrudStore

A list over an add-on's own service, typed from its declaration (MICA-313).

The declaration your server half registers, and the actions to use from it. Every name is one of the declaration's, and the store's types follow from the declaration rather than from a type argument you assert:

• list answers addonOutput<Row[]>(), and Row — which needs an id: number — is the store's row type. It is called with no input.
• create takes the draft, so add(draft) is typed as its input, and answers the created row (addonOutput<Row>()).
• update is sent the whole row, so its input declares every field of Row.
• remove is sent { id }.

const notes = createCrudStore(notesService, { list: 'list', create: 'add' });
await notes.add({ text }); // a typo in a field, or in an action name, fails to compile
Copy

At run time it is createCrudStore(declaration.id, events, { ...options, service: declaration.id }): the same store, through the same generic service route. The types are a convenience and a promise about nothing — the server parses every payload against the declaration it was handed, and the shell refuses any id but your own, whatever this side believed.

A store over a list of rows the server owns.

Four stores had written the same load/add/update/delete by hand, and every difference between them was an accident rather than a decision:

• Order — see sort above.
• Optimism — Mail wrote to the list first and then told the server; everyone else waited. Optimism was load-bearing when fetchNui swallowed failures, because there was no other way to feel responsive. It now throws, so the list follows the server and a refused write no longer leaves the UI asserting something untrue.
• Validation — Contacts checked its required fields, in the store and again in the component; nobody else checked anything.
• Bad data — three stores logged and emptied the list on a non-array reply, one let it through. Now a non-array reply is a failed load (MICA-384): logged, and the list and loaded are left as they were.

Neither reads nor writes pass a defaultValue, so fetchNui throws on failure instead of masking it. Writes propagate the throw to the caller, which already had a value to fall back to. load catches it itself and keeps the store's last known list — the store has nothing better to show, and a background refresh that failed should not wipe out what the player was already looking at. Nor does it set loaded: a first load that failed leaves the store still loading, and calling load again is the retry.