[eliranhe]

Description

Feature: two additions to state effects (transition / transitionProperties).

1. elementStyles: a state that styles other elements of its key.

• A state effect can now list declarations it sets on other elements of its key.
• Each entry's selector is resolved inside the key's element, the same way an effect's selector is.
• generate() writes one more state rule per entry. The rule is under the same :is(:state(<effectId>), :--<effectId>) / [data-interact-effect~="<effectId>"] selectors as the target's own rule, and createTransitionCSS renders the same rules at runtime.
• The state still toggles once per trigger, however many elements it styles.

{
  key: 'card',
  selector: '.card',
  effectId: 'hovered',
  transition: { styleProperties: [{ name: 'transform', value: 'scale(1.05)' }] },
  elementStyles: [{ selector: '.card .title', styleProperties: [{ name: 'color', value: 'crimson' }] }],
}

2. States that code toggles.

• A state effect in config.effects that no interaction or sequence references now declares the look of a state that code toggles with toggleEffect. It is named by its effectId, or else by its entry's id (getCodeStates).
• generate() writes its rules.
• At runtime, add() renders them when the key's element connects. It honors the effect's media conditions, re-rendering through a media-query listener when they change, and its selector condition.
• A referenced effect is left to its interaction, as before.

Today both are dropped. elementStyles isn't part of StateEffect, and nothing caches an effect that no one references, so its look has nowhere to come from.

Related Issue

No issue filed. This came up in the Wix viewer (Thunderbolt), which is moving component state styles off its own CSS and into the interact config. Those are the hover, click and other states authored in the editor.

• A state there often styles elements of the component other than the state's target, for example a button's label.
• Site code can toggle states that no trigger sets.

Without these two additions the viewer has to keep its own CSS for both cases.

Checklist

• I have read the Contributing Guide.
• Tests: packages/interact/test/stateLooks.spec.ts covers both features in generate() and at runtime, plus a referenced state effect staying with its interaction. On this commit, yarn workspace @wix/interact test (496 tests), yarn lint and yarn format:check pass.
• Docs: only the type doc comments (ElementStyle, getCodeStates) for now. I'll add the rules/docs pages once the API shape is agreed.

Screenshots / Demos

packages/interact/repro/state-looks.html: build with yarn workspace @wix/interact build, serve the repo root, and open the page.

• Hovering the card scales it (its own look) and colors its title (an elementStyles entry of the same state).
• The button toggles selected from code. No interaction sets that state, so its look comes from config.effects.

Additional Notes

• Branched from 2.5.18 (971a565); it merges cleanly onto master (2.5.19).
• createTransitionCSS was refactored to build every state rule through one helper (stateRule), so the target's rule and the elementStyles rules share the selector-condition handling. The target's rule output is unchanged.
• Draft, to agree on the API before docs: the elementStyles name and shape, and whether code-toggled states should be declared explicitly rather than inferred as "unreferenced".

🤖 Generated with Claude Code