Context, Tools, and Events

This part of the custom-module docs describes the injected runtime surface you work with after extending StringModule.

Every custom module constructor receives a StringContext.

constructor(context: StringContext) {
  super(context);
}

The base class stores that context on protected fields like:

• this.tools
• this.data
• this.settings
• this.events
• this.centers
• this.hover
• this.objectManager

That surface is too important to keep on one long page, so it is split into focused deep dives.

What belongs here

This cluster answers four different authoring questions:

1. What exactly is available in StringContext?
2. Which tools should a custom module reuse instead of reinventing?
3. How should live runtime state be read from this.data?
4. How should custom modules subscribe to and emit events?

Practical Rule

Good custom modules usually stay inside this surface:

• read shared runtime state from this.data
• read author config through attribute mapping and this.settings
• reuse this.tools for parsing, interpolation, and writes
• use this.events for safe runtime communication

If a module starts depending heavily on private manager internals instead of these injected surfaces, that is usually a design smell.