Lifecycle directives

Lifecycle directives control how data flows over time in a Sercrod application: how edits are staged, how values are saved and loaded, how HTTP requests are made, and how real-time connections are handled.

This page groups the main lifecycle-related directives by purpose and links to more detailed reference pages where available.

Staging edits: *stage, *apply, *restore
Saving and loading: *save, *load
HTTP lifecycle: *fetch, *post, *api, *into
Real-time lifecycle: *websocket, *ws-send (and n-ws-send alias)

Staging edits: stage, apply, *restore

The staging directives let you edit data in a temporary branch and then either commit or discard those changes. This is useful for forms where you do not want to update the main data on every keystroke.

*stage marks a subtree as working on staged data instead of the main data. Inputs inside the staged subtree write into a separate branch managed by Sercrod.
*apply commits the staged values back to the main data.
*restore discards staged changes and restores the previous main data into the staged branch.

Basic pattern

A common pattern is to stage a form and then have explicit “Save” and “Reset” buttons that control when the main data is updated.

<serc-rod
  id="profile-app"
  data='{"profile": { "name": "Taro", "email": "taro@example.com" }}'
>
  <form *stage>
    <label>
      Name:
      <input type="text" :value="profile.name">
    </label>

    <label>
      Email:
      <input type="email" :value="profile.email">
    </label>

    <button type="button" *apply>Save</button>
    <button type="button" *restore>Reset</button>
  </form>

  <p>Current name: %profile.name%</p>
  <p>Current email: %profile.email%</p>
</serc-rod>

Inside the staged form, the user can type freely. The main profile data is only updated when *apply runs. *restore brings the staged copy back to the last committed state.

Saving and loading: save, load

*save and *load coordinate data with a persistent store such as local storage or another backing mechanism defined by the application.

*load loads stored data into the current Sercrod scope when the host is initialized.
*save writes the current data (or a selected part of it) back to the store when triggered.

The exact storage backend and key scheme are defined by Sercrod configuration or by project conventions. See the dedicated pages for detailed signatures and configuration options.

Typical pattern

<serc-rod id="todo-app" *load>
  <ul>
    <li *each="item of todos">%item.label%</li>
  </ul>

  <form>
    <input type="text" :value="new_label">
    <button type="button" @click="
      if(new_label){
        todos.push({ label: new_label });
        new_label = "";
      }
    ">Add</button>
  </form>

  <button type="button" *save>Save list</button>
</serc-rod>

In this pattern, *load restores any previously saved state for the host when it starts, and *save commits the current list to storage on demand.

HTTP lifecycle: fetch, post, api, into

These directives coordinate HTTP calls and how their results enter or leave the Sercrod data model.

*fetch performs a request (typically GET) and receives a JSON response.
*post sends data (typically JSON) to an endpoint.
*api defines or selects an API configuration such as base URL, headers, or common options.
*into controls where the received data is placed inside the Sercrod scope (for example a specific property or subtree).

The exact combination and signatures depend on the project’s API design and Sercrod configuration. The following example shows a simple “load list” and “submit form” pattern.

Example: load and submit data

<serc-rod id="users-app">
  <section *fetch *into="users">
    <h2>Users</h2>
    <ul>
      <li *each="user of users">%user.name%</li>
    </ul>
  </section>

  <form *post *into="users">
    <input type="text" :value="new_name">
    <button type="submit">Create</button>
  </form>
</serc-rod>

In this pattern, *fetch loads the initial list into users, and *post sends form data to the server. The response is merged back into the same list via *into. See the dedicated HTTP directive pages for complete details and error-handling strategies.

Real-time lifecycle: websocket, ws-send

Real-time directives connect Sercrod to a WebSocket server and send or receive messages while keeping the data model in sync.

*websocket opens and manages a WebSocket connection for the host.
*ws-send (and its alias n-ws-send) sends data over that connection, typically in response to a click or other event.

WebSocket directives often work together with special variables such as $ws_ready, $ws_last, and $ws_close_code to reflect the connection state and the latest message.

Example: simple chat outline

<serc-rod id="chat-app" *websocket>
  <p *if="$ws_ready">Connected</p>
  <p *else>Connecting...</p>

  <ul>
    <li *each="msg of messages">%msg.text%</li>
  </ul>

  <form @submit="
    if(new_message){
      // *ws-send will use this payload
      messages.push({ text: new_message });
      new_message = "";
    }
  ">
    <input type="text" :value="new_message">
    <button type="submit" *ws-send="messages">Send</button>
  </form>
</serc-rod>

This outline shows how a WebSocket connection can reflect its state in the UI, and how *ws-send can be used to send data that is also tracked in the Sercrod data model. The exact connection details and payload format depend on the project’s WebSocket server.

Choosing lifecycle directives

Use staging directives when a user should be able to edit a complex form and then explicitly commit or discard changes.
Use save/load when state should survive a page reload or be restored between sessions.
Use HTTP directives when interacting with REST-like or JSON APIs.
Use WebSocket directives when you need live updates, bidirectional communication, or presence information.

Lifecycle directives

Staging edits: *stage, *apply, *restore

Basic pattern

Saving and loading: *save, *load