selfstore-destination

Once the data has a durable home, this is the panel that says so: where it saves, when it last wrote, and what you can do about it.

<selfstore-destination id="dest"></selfstore-destination>

const el = document.getElementById('dest');
el.confirmAction = (a) => confirm(`Stop saving to ${a.label}?`);
el.targets = { drive: driveAuth, file: true };

It reads the store through the same engine the other widgets use, so it needs no store property of its own. Mounted inside <selfstore-storage> it appears on its own once there is a home.

It does the work

Exporting a copy, detaching and re-connecting are the engine’s own operations, so this panel performs them rather than emitting an intention for your app to implement. A panel that only announced what the user wanted would leave the same two hundred lines in every app - the lines it exists to delete.

One exception, and it is structural. Loading a copy back cannot happen from here: the library holds no records, your apply does. The engine exposes exportBlob() and no import, so the panel asks for that one through the selfstore-destination-action event and your app runs its own import.

Properties

interface DestinationAction {
	type: 'detach';
	label: string | null;
}

confirmAction defaults to proceeding, and the panel never invents its own dialog: your app has its own words and its own modal. Answer false and nothing happens.

Detaching never deletes. It stops writing here; the backup already written stays where it is.

Two things stay yours

The words - every label is overridable and a pack ships per language, see wording - and the veto on what is destructive. Neither is customisation: they are the decisions a library must not take for an app.