Context

Every custom module constructor receives a StringContext. In practice, StringModule copies that context onto protected fields, so custom modules usually work through this.* instead of keeping the raw context reference around.

What StringContext Contains

The current runtime provides:

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

How You Usually Access It

Inside a custom module, use:

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

That is the normal authoring path. Reaching back to the original constructor argument usually adds noise but no value.

this.settings

this.settings is the merged module-level settings object.

Its inputs are:

• global defaults from stringTune.setupSettings(...)
• per-module overrides from stringTune.use(MyModule, settings)

Use this.settings for module-wide defaults, not for per-element state.

Good uses:

• default strength
• default radius
• fallback CSS variable key
• module feature toggles

this.objectManager

this.objectManager is the most advanced surface in the context. Most custom modules should touch it rarely.

The most practical public-ish use is forcing layout refresh after DOM changes:

this.objectManager.refreshLayoutForRoot(object.htmlElement);

Use this sparingly. If a module needs it constantly, the DOM design is usually too heavy.

this.centers and this.hover

These are helper surfaces for more advanced interaction work.

• centers helps with cached center lookups and invalidation
• hover exposes hover tracking helpers

They are useful when a module genuinely needs those runtime caches. For many modules, data, settings, tools, and events are enough.

Mental Model

Think of StringContext as the dependency-injection layer for custom modules:

• data gives you live runtime facts
• tools gives you shared parsers and helpers
• events gives you communication
• settings gives you module defaults

Everything else is support structure around those main surfaces.