Strictness

Qite Components may declare a static strict = { ... } object to verify that certain things they depend on really exist. This is a lightweight safety net for component structure and capabilities — it helps catch cases where a template changed, a child Component is missing, a required method disappeared, or some other assumption made by the Component is no longer true.

Strictness is deliberately optional. It isn't meant to describe everything a Component contains. Instead, it lets a Component state which parts of its environment are important enough that their absence probably means something is wrong.

By default, strictness reports warnings through the Component logger, so you'll get a console WARNING explaining which Component or Behavior declared the requirement and which target is missing.

Basic usage

A strictness declaration may include the following keys:

• parts
• fields
• flags
• children
• parent
• selectors
• methods
• behaviors

Declare strict targets on the Component class like this:

class CheckoutForm extends BaseComponent {
    static strict = {
        parts:     ["title", "actions"],
        fields:    ["email", "name"],
        flags:     ["submitting"],
        children:  [{ roles: "submit" }],
        parent:    "RootComponent",
        selectors: [".checkout-marker"],
        methods:   ["submit"],
        behaviors: ["popup"]
    };
}

Qite checks every declared target against the Component.

A strict declaration does not create any of these things. It only verifies that they are already present.

Parts

parts verifies DOM parts declared with data-part

static strict = {
    parts: ["control", "value"]
};

For example, "control" expects the Component to contain a corresponding data-part="control" element.

Fields

fields verifies fields registered on the Component.

static strict = {
    fields: ["label", "value"]
};

This is useful when the JavaScript implementation assumes that particular fields were supplied by the Component's HTML.

Flags

flags verifies flags registered on the Component.

static strict = {
    flags: ["opened", "disabled"]
};

Use this when a method or Behavior depends on a flag being part of the Component's state.

Children

children verifies direct child Components using the same criteria accepted by findChildren()

static strict = {
    children: [
        { roles: "submit" },
        { roles: "cancel" }
    ]
};

Each entry represents a child Component that must exist.

Parent

parent verifies the expected parent Component.

static strict = {
    parent: "RootComponent"
};

Use this when the Component is only meaningful inside a particular parent Component.

Selectors

selectors verifies ordinary DOM selectors inside the Component.

static strict = {
    selectors: [".menu", "[data-status]"]
};

Parts should normally be preferred when an element is explicitly part of a Component's public DOM structure. Selectors are useful for other structural requirements that don't need to become named parts.

Methods

methods verifies that the Component provides particular methods.

static strict = {
    methods: ["open", "close"]
};

This is particularly useful for reusable Behaviors that depend on capabilities of their owning Component.

Behaviors

behaviors verifies that named Behaviors are attached to the Component.

static strict = {
    behaviors: ["popup"]
};

Behavior names are the same names used with the Component's behaviors manager:

this.behaviors.get("popup");

Strictness in Behaviors

Behaviors may declare static strict as well. Unlike Component strictness, a Behavior's declaration describes requirements of its owning Component. The Behavior itself is not treated as a miniature Component with its own parts, fields, flags or children.

For example:

class ExampleBehavior extends Behavior {
    static strict = {
        parts:   ["control"],
        flags:   ["disabled"],
        methods: ["close"]
    };
}

When this Behavior is attached, Qite verifies those requirements against the Component that owns it. This lets reusable Behaviors clearly state what kind of Component they can operate on without introducing a separate interface or inheritance hierarchy.

Behavior strictness is checked after the owning Component has mounted, so its Component structure and children are available before the requirements are validated.

What happens on failure

Strictness is handled by the shared Strictness class. By default, failures are reported through the Component logger with log level WARN. A typical warning explains that a particular target was declared as strict but could not be found. Unknown strictness keys are reported too. For example:

static strict = {
    bananas: ["banana"]
};

This reports:

Unknown strictness type: bananas

When a Behavior declared the requirement, the warning identifies the Behavior as the declarer while still checking the requirement against its owning Component.

Error mode

Strictness uses:

Strictness.error_type = "WARN";

If you want strictness failures to be treated as errors instead, set:

Strictness.error_type = "ERROR";

This is useful in tests or during aggressive development, when you want broken Component assumptions to fail immediately instead of merely warning.

When to use strictness

Strictness is best for things that a Component or Behavior genuinely depends on. It helps uncover mismatches between separately maintained HTML and JavaScript, especially when server-rendered templates may change independently of the Component code.

Do not use it to inventory everything in a template. Optional targets should not be made strict merely because they sometimes exist. In short: use strictness for assumptions whose failure would make the Component or Behavior invalid, misleading or unable to do its job.