Initial implementation of interactor#242
Conversation
Generated
|
| { | ||
| "id": 1, | ||
| "name": "plain-html-add-entrance-and-hover", | ||
| "prompt": "I have a plain static HTML landing page — no build tools, no framework, I just edit index.html and open it in the browser. I want to add some motion: make the hero section fade in when it scrolls into view, and make the 'Get Started' CTA button grow a little when you hover it. I'd like to use Wix's @wix/interact library for this. Walk me through it and give me the code.", |
There was a problem hiding this comment.
these prompts are very detailed compared to the average-user's prompt. Maybe we should have some simpler prompts for evaluations?
There was a problem hiding this comment.
I think it's fine. Yeah, not a one liner, but reasonable.
| "id": 1, | ||
| "name": "plain-html-add-entrance-and-hover", | ||
| "prompt": "I have a plain static HTML landing page — no build tools, no framework, I just edit index.html and open it in the browser. I want to add some motion: make the hero section fade in when it scrolls into view, and make the 'Get Started' CTA button grow a little when you hover it. I'd like to use Wix's @wix/interact library for this. Walk me through it and give me the code.", | ||
| "expected_output": "Sets up @wix/interact via the /web (custom-element) entry point loaded from a CDN (no build step). Registers presets with Interact.registerEffects before create/generate. Hero: viewEnter trigger + FadeIn namedEffect with triggerType:'once', wrapped in <interact-element data-interact-key=...>, with FOUC handled correctly (injected generate(config, true) output). CTA hover-grow avoids the hit-area-shift pitfall (animates a child via selector, or uses a state/transition effect, or targets a separate key) rather than scaling the same hovered element. generate() called with useFirstChild=true for the web entry point. No invented preset names; no Bg*/DVD presets.", |
There was a problem hiding this comment.
some of these could be validated deterministically
There was a problem hiding this comment.
We can try let the model see if it can use more static validation for these
| "assertions": [ | ||
| "Uses @wix/interact correctly: imports the Interact API and calls Interact.create(config) with a valid InteractConfig.", | ||
| "Registers presets before use: Interact.registerEffects(...) is called BEFORE create/generate when a namedEffect is used.", | ||
| "Hero entrance correct: trigger 'viewEnter' + FadeIn namedEffect with triggerType:'once'.", | ||
| "FOUC handled: generate() output injected.", | ||
| "generate() useFirstChild matches the entry point (true for /web custom elements, false for vanilla).", | ||
| "Hover-grow avoids hit-area shift: scales a child/separate target or uses a state/transition effect, not the same hovered element.", | ||
| "No invented or forbidden presets (no Bg*/ImageParallax/DVD/made-up names).", | ||
| "Runnable with no build step: index.html is self-contained (CDN/module import)." |
There was a problem hiding this comment.
Also here we could have some of those validated deterministically. Some can even be checked statically.
There was a problem hiding this comment.
Also here, we can try let the model see if it can use more static validation for these
| | Package | Role | You touch it… | | ||
| | :-------------------- | :--------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------- | | ||
| | `@wix/interact` | Declarative layer. Binds **triggers → effects** via an `InteractConfig`. Ships vanilla / React / Web-Component entry points. | Always. This is the API. | | ||
| | `@wix/motion-presets` | ~62 ready-made named effects (entrance, scroll, ongoing, mouse). Referenced as `namedEffect: { type: 'FadeIn' }`. | When you want a prebuilt effect (the common case). | |
There was a problem hiding this comment.
Let's remove the amount of presets that usually become stale fast
| | `@wix/motion-presets` | ~62 ready-made named effects (entrance, scroll, ongoing, mouse). Referenced as `namedEffect: { type: 'FadeIn' }`. | When you want a prebuilt effect (the common case). | | |
| | `@wix/motion-presets` | ready-made named effects (entrance, scroll, ongoing, mouse). Referenced as `namedEffect: { type: 'FadeIn' }`. | When you want a prebuilt effect (the common case). | |
|
|
||
| 1. Choose the **trigger** (see decision table below). | ||
| 2. Choose the **effect**: prefer a `namedEffect` preset (browse `references/presets.md`); fall back to inline `keyframeEffect` for custom keyframes, or `customEffect` for non-CSS (SVG/canvas/text). | ||
| 3. Set the **playback field** the trigger needs: `triggerType` for time effects on hover/click/viewEnter; `stateAction` for CSS-state (transition) effects; `rangeStart`/`rangeEnd` for `viewProgress`. Never set both `triggerType` and `stateAction` on one effect. |
There was a problem hiding this comment.
playback field is a weird name that does not have any references in our project and seems to be wrong here. Let's use auxiliary fields or something like that
There was a problem hiding this comment.
Everything related to the effect is usually called "playback". Also in specs. This is quite common.
Regarding triggerType and stateAction, while I agree they're more about the action than playback, they're still set on the effect, so I think models will understand it
| | `triggerType` | Behavior | | ||
| | :----------------- | :------------------------------------------------------ | | ||
| | `'once'` (default) | Play once, the first time it enters. The entrance case. | | ||
| | `'repeat'` | Replay every time it re-enters. | | ||
| | `'alternate'` | Play forwards in, reverse out. | | ||
| | `'state'` | Play on enter, pause on exit. | |
There was a problem hiding this comment.
this (and only this IMO) is the kind of information that is needed in these references - translation from the type to the semantic meaning. Other than that, almost everything here can be inferred from types and validations
There was a problem hiding this comment.
The schema and types don't contain descriptions. Here we have more descriptions to explain what things do for the model.
| | `'remove'` | remove on enter | remove on click | | ||
| | `'clear'` | clear all states on enter | clear all states | | ||
|
|
||
| **CRITICAL — hit-area shift:** if a hover effect changes the element's size or |
There was a problem hiding this comment.
again - could be added to interact-validate
| @@ -0,0 +1,143 @@ | |||
| # Motion engine reference (@wix/motion) — escape hatch | |||
|
|
|||
| `@wix/motion` is the engine `@wix/interact` is built on. **On the interact-first | |||
There was a problem hiding this comment.
is this necessary? Do we actually have use-cases where we want the agent to use motion directly?
There was a problem hiding this comment.
Maybe not. I thought it would be interesting to leave it out there just for kicks. WDYT?
| @@ -0,0 +1,218 @@ | |||
| # Preset catalog (@wix/motion-presets) | |||
|
|
|||
| The 62 production presets, by category, with parameters and defaults — plus an | |||
There was a problem hiding this comment.
Yes, remove exact number
|
|
||
| --- | ||
|
|
||
| ## Entrance (19) — for `viewEnter` (time-based) |
There was a problem hiding this comment.
please remove all the numbers that reflect amounts of presets - they give no new information (counting lines in tables is not hard) and they just become stale
There was a problem hiding this comment.
Yep, let's remove all the exact number of presets
Description
Implementing the
/interactorskill for adding interact to a page, either using/webor/react, or editing an existing interact integration.