Enabled property — works on switch controls?

Elements API
1

Hi Dan,

I’m trying to use the enabled key (documented at https://docs.realmacsoftware.com/elements-docs/elements-language/component/properties-json/general-structure/enabled) to conditionally disable a switch control, but it seems to have no effect.

Use case: I’m building a popover-style component where the “Caret” toggle should be unavailable when the user sets the popover’s background opacity below 100% — with any transparency, the caret would have visible seams against the popover edge, so I’d like to lock the switch to prevent users from enabling a feature that won’t render properly.

Diagnostic test that I think proves the issue:

{
    "title": "Enable",
    "id": "myProp",
    "switch": { "default": false },
    "enabled": "false"
}

I’d expect the switch to be permanently greyed out / non-interactive. Instead, it remains fully toggleable — enabled appears to be silently ignored on switch controls. Same behavior with any expression I try ("true", "false", or comparisons against other props).

What I’ve ruled out:

  • properties.json builds cleanly, no warnings

  • RapidWeaver fully closed and reopened (no inspector schema cache)

  • visible expressions work correctly on the same component, including with responsive prop values (e.g. "caretEnabled == true && contentBgOpacity < 100" correctly shows/hides info text per-breakpoint)

A few questions:

  1. Is enabled supported on switch controls? The docs state it works “the same way as visible”, which suggests yes.

  2. If yes — am I missing something in the syntax?

  3. If no — could the docs note which control types it’s supported on? And what’s the recommended pattern to conditionally lock a switch state based on another property’s value?

Thanks!

2

Good catch, that one’s on us! It was a typo in the docs, which I’ve now corrected.

The correct property is enable, not enabled.

Cheers!

3

Thanks @tpbradley that fixed it for the basic case! :tada:

I confirmed enable now works on a switch control with non-responsive comparisons, e.g.:

{
    "title": "Enable",
    "id": "myToggle",
    "switch": { "default": false },
    "enable": "myOpacity == 100"
}

When myOpacity is a non-responsive slider, the switch correctly greys out as the user moves the slider below 100.

Possible follow-up issue I noticed while testing: enable doesn’t seem to react to responsive prop values, while visible does.

Same expression, two different behaviors:

// This DOES update per-breakpoint when myOpacity is responsive
"visible": "myOpacity == 100"

// This does NOT — switch stays in the same state regardless of which breakpoint dot the user edits
"enable": "myOpacity == 100"

When myOpacity is responsive ("responsive": true), I’d expect both to evaluate the value at the current breakpoint and update reactively. visible does (info paragraphs show/hide correctly when I move the value below 100 at any breakpoint). enable keeps the switch in its initial state.

Is enable perhaps using a different evaluation path that doesn’t yet handle responsive props? Could it be aligned to match visible’s behavior in a future update?

In the meantime my runtime already handles this correctly via JavaScript (reads computed alpha and skips rendering when transparent), so this is just a UX nicety — but it would make the inspector feedback more consistent.

Thanks!