Storage & State nodes
tailrmade provides several ways to store and retrieve data. Each storage tier serves a different purpose:
| Tier | Persistence | Scope | Sign-in required |
|---|---|---|---|
| Session (in-memory) | Until page reload | Current session | No |
| IndexedDB | Until browser data is cleared | Current browser | No |
| Cloud Storage (Tailrmade) | Permanent | Any device | Yes |
Storage
The Storage nodes are a unified set of nodes for reading, writing, deleting, and browsing data across browser and cloud backends. All nodes expose a Storage type input that lets you switch the underlying backend without rewiring your graph:
| Backend | Default | Best for |
|---|---|---|
| IndexedDB | Yes | Larger or more structured data, many records, metadata-driven browsing |
| Session | No | Temporary shared state, selections, counters, and values that reset on page reload |
| Cloud | No | Signed-in user data that should follow the user across devices |
The Storage type defaults to IndexedDB. Change it to Session for temporary in-memory state, or Cloud when the data should be stored for the signed-in user. Session uses the same Read, Write, Update, Delete, and Browse nodes; writes notify matching readers. Session data is isolated to the currently loaded app and resets when an app is loaded or cleared, or on page reload and does not use the browser sessionStorage API.
Common patterns
All storage tiers share a consistent socket naming convention:
| Socket | Direction | Description |
|---|---|---|
| Location | Input | A namespace/category for grouping keys (defaults to the current graph) |
| Key | Input | The identifier within a location |
| Value | Input/Output | The data to write or read |
| Fallback value | Input | Returned when the key does not exist (Read nodes) |
| Success | Output | true when the operation completed successfully |
| Error | Output | Error message if the operation failed, empty otherwise |
| Show Toast Notification | Input | Optional toast feedback for read, write, delete, and browse |
Write controls
Write and delete nodes use manual execution — they only run when their Execute trigger socket fires. This prevents accidental writes during graph loading or upstream changes.
Write nodes include two boolean inputs:
| Input | Default | Behaviour |
|---|---|---|
Non-empty only | true | Skips the write when the value is null, undefined, "", [], or {} |
Insert only | false | Writes only when the key does not already exist |
When a write is skipped, the Error output contains the reason.
Execute trigger
Write and delete nodes have an Execute trigger socket. Connect any trigger source to it — the node will run its operation when the trigger fires. This matches their manual update behaviour.
Read node updates
State/Storage Read follows the node's update behaviour:
- With on change enabled, the node re-executes not just on socket change but also when the matching stored value changes for its selected Storage type, Location, and Key
- With on change disabled, the node only updates when executed manually or by a trigger socket
If the Key input is empty, Storage Read treats the whole location as its source and updates when that location changes.