Scoped Token Constants (STCs)

Introduction

A Scoped Token Constant (STC) is a locally defined string or template literal that contains one or more Tailwind utility classes or token references. It is scoped to the module or component and is intended to improve DRYness, semantic reuse and readability of className values within JSX/TSX files.

STCs are recognized by Sentinel as a legal styling construct alongside NSOs. They are most useful when;

  • a style group is specific to a component;

  • too lightweight for a dedicated NSO; or,

  • needs to be composed dynamically.

Why STCs Exist

STCs were introduced to address styling needs that;

  • do not require file-based grouping (like .css files used for NSOs);

  • are inline but reused, such as button clusters, layout blocks or text groups;

  • must be composed dynamically using template strings or cn(…); and,

  • need access to Tailwind tokens such as theme(…), –color-* or min-w-[…] inside the className.

They complement, but do not replace, NSOs.

Valid STC Shapes

  1. Basic constant
				
					const FORM_BUTTON = "min-w-[320px]";

used in

				
					<Button className={FORM_BUTTON}>Submit</Button>

2. Template Literal

				
					<Button className={`${FORM_BUTTON} px-4 py-2`}>Submit</Button>

3. Composed with cn()

				
					<Button className={cn(FORM_BUTTON, "text-white", isDanger && "bg-red-600")}>
  Delete
</Button>

Sentinel Guidelines for STCs

Rule

Description

Semantic naming

Constants must be named clearly, with UPPER_SNAKE_CASE or camelCase depending on scope

DRY scope

Should represent a meaningful reusable pattern, not a one-off

Tailwind tokens only

STCs may contain Tailwind utilities, token references (e.g. min-w-[…], var(–…)), or theme(…) values

JS-only

STCs are for use in .ts, .tsx or .js files — not in .css or .nso.ts blocks

Optional nesting

May be combined using cn() or template literals for dynamic styling needs

Never replace NSOs

Use an NSO when structure, reviewability or grouping is required

STCs vs NSOs — Comparison

Feature

STC

NSO

Local reuse

✅

❌ (global)

File-based style block

❌

✅

Grouped by property

❌

✅

ClassName-driven

✅

❌

Token compatible

✅

✅

Reviewable structure

⚠️

✅

Composition (cn())

✅

❌

Why STCs Are Partially Reviewable

Construct

Reviewable?

Why

NSOs

✅ Fully reviewable

File-based, named, grouped by property, formatted with comments and spacing

STCs

⚠️ Partially reviewable

Often defined as local string constants; no grouping, no enforced structure, not always semantically named

 

⚠️ The Warning Means:

STCs are technically readable but not self-describing.

They are not structured by design — and therefore do not meet Sentinel’s full review clarity standard.

For example:

				
					const FORM_BUTTON = "min-w-[320px]";

✅ It’s DRY and reused.

❌ But a reviewer doesn’t know if it includes spacing, interaction, or visual decoration.

❌ There’s no grouping, no spacing, and no audit trail.

It must be reviewed where it is used, not on its own terms.

NSO Comparison

				
					.form-button {

  /* 1. Layout */

  min-width: 320px;

  /* 4. Spacing */

  padding: theme(spacing.3);
}

A reviewer sees exactly what it governs, grouped and sorted.

⚠️ STCs are legal but informal.

They improve developer experience and DRYness, but they don’t replace structured, reviewable styles like NSOs.

You can use STCs freely — just don’t confuse code convenience with style governance.

STC Reviewability Note

While Scoped Token Constants (STCs) improve clarity and reuse within a module, they lack formal structure and cannot be audited independently. STCs are not grouped by canonical property, do not include comment headings or spacing, and offer no guarantee of semantic scope. They are reviewable only in context, not in isolation — and should never be mistaken for full styling contracts.

Use STCs for local DRYness, not system governance.