Templating

Monster templating is the fastest way to connect plain DOM and application data without inventing a component first. The Updater reads data-monster-* attributes, keeps a proxied subject in sync and updates the DOM through explicit rules.

Tutorial Goal

Build a small bound view with one subject and several update rules

By the end of this tutorial you will know when to use data-monster-replace, data-monster-bind, data-monster-insert and why the proxy returned by Updater is the object you should mutate.

Check the first page tutorial Open Playground

Before You Start

Have a working Monster setup

If you still need npm install, browser imports or the example file layout, stop here and open First Page first.

Know the boundary

Updater is for binding an existing DOM subtree to data. If you need your own tag, Shadow DOM or a reusable UI primitive, switch to CustomElement.

Use the proxied subject

Construct Updater with a plain object, then work against updater.getSubject(). That proxy is what triggers change propagation safely.

The Minimal Flow

1. Import the runtime class

Use the current ESM entrypoint, not the older .js path.

import { Updater } from "@schukai/monster/source/dom/updater.mjs";

2. Mark the DOM with explicit rules

Keep the template honest. The HTML should reveal what gets replaced or bound.

<section id="account-card">
    <h2 data-monster-replace="path:title"></h2>
    <p data-monster-replace="path:description"></p>
    <input type="text" data-monster-bind="path:title">
</section>

3. Create the updater

Bind the root element and your initial subject.

const root = document.getElementById("account-card");

const updater = new Updater(root, {
    title: "Starter Account",
    description: "This content is synced from the subject."
});

const subject = updater.getSubject();
await updater.run();

4. Mutate the proxy, not the original object

The proxy is the public update surface. Changes there propagate back into the DOM.

subject.title = "Updated Account";
subject.description = "The paragraph changes without manual DOM code.";

Live Updater Demo

This block uses the same `data-monster-*` attributes from the tutorial. Edit the fields or load one of the presets and the output updates through the Updater subject.

Title

Description

Status

Current status:

Load launch preset

Load review preset

Important mental model

Updater is not a generic magic observer on every JavaScript reference in your app. It reacts through the subject it owns. If you bypass that subject, you are also bypassing the update mechanism.

Core Attributes

Attribute	Use it for	Typical mistake
`data-monster-replace`	Replacing text or markup output with a path or static pipeline.	Using it where a repeated structure should actually be a template insert.
`data-monster-bind`	Two-way binding on input-like controls.	Forgetting `data-monster-bind-type` on non-string values.
`data-monster-insert`	Rendering repeated structures from a template and iterable data.	Trying to build list DOM manually while also expecting Updater to own it.
`data-monster-attributes`	Projecting subject values into HTML attributes.	Pushing visual state into hard-coded classes instead of token-based classes or public options.
`data-monster-remove`	Removing nodes based on updater evaluation.	Using removal where simple conditional replacement would keep layout more stable.

Type Handling for Bound Inputs

If the field is not just a string, define the binding type explicitly. That keeps the subject stable and avoids subtle coercion bugs later in your pipeline.

Numbers

Use number, int, float or integer when the subject should stay numeric.

Booleans

Use boolean, bool or checkbox for checkboxes and other boolean surfaces.

Arrays

Use array or list when the input represents a comma-separated set of values.

Objects

Use object or json only when users really edit structured data directly.

Common Mistakes

Mutating the wrong object

Construct with a plain object if you want, but after setup always mutate the subject returned by getSubject().

Mixing manual DOM work with updater-owned DOM

If Updater owns a subtree, let it own it. Manual mutations inside the same structure create hard-to-reason races.

Using binding when options would be clearer

When you are already inside a Monster component, prefer its public options and methods instead of reaching in with extra updater rules.

From Tutorial to Real Control

Templating to Select

Move from bound DOM to mapped options

Select uses the same basic thinking as the updater tutorial: values are mapped into stable DOM output instead of being stitched together manually. Once you understand templates, labels, values and option binding, the control API becomes much easier to reason about.

Open Select documentation Continue into CustomControl

What to inspect

Check mapping, options and repeated content

Focus on label/value templates, datasource-backed records and the way the component keeps rendering concerns separate from the data contract. That is the same separation you just used with Updater, only packaged as a reusable control.

Open Updater API

Where to Go Next

Continue into Datasource

If the DOM binding layer is clear and you now need stable loading and persistence contracts, move on to the Datasource tutorial.

Open Datasource tutorial

Read the API contract

For the full class details, continue to Updater.

Open API page

The current width of the area is too small to display the content correctly.