Add Boolean property type#837
Conversation
08d7bf4 to
f177304
Compare
Adds a `boolean` property type for true/false values, mirroring the
recently-merged Select pattern. `BooleanValue` and the
`ValueType::Boolean` deserialization path already existed in both PHP
and TS; this PR adds the type wrapper, property definition, schema and
subject UI, and registration.
Schema JSON: `{ "type": "boolean" }`. No type-specific attributes;
`default` may be `true`, `false`, or `null`. The construction-time check
rejects non-boolean defaults, slightly stricter than siblings.
`BooleanInput` always emits a `BooleanValue`, so a Boolean field is
never "unset" once interacted with. The input renders as a single
inline `label [switch]` row to match the `Require a value` row directly
above it in the schema editor.
Demo data: `Is public` on the Company schema (true on ACME Inc), plus
three Boolean variants in the Everything showcase schema.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
f177304 to
652b3a0
Compare
|
I went with the toggle, because that's what we use elsewhere for boolean inputs. However, I have a feeling there's a slight difference between "toggling config" and "setting a yes/no value". With the latter falling more into checkbox category for me. On the other hand, mixing toggles and checkboxes might look odd, and in this case the checkbox would not be for selecting items in a list. In either case, for displaying the value I went with "yes/no" text, because the rest of the infobox is also text. We could go with some kind of checkmark/cross icon, but that would be inconsistent with what we have now. |
|
Sidenote: every time i see those codex toggles with the text on the left and the toggle on the far right i think they look bad 
|
There's an option to have it next to text. They look nicer when there is a description field. On a form with multiple toggle switches, it's more scannable and less ugly if they are all aligned at the end. |
I had a deep dive on the Codex docs, and you are right. It is recommended to use checkbox over toggle switch when the option does not trigger immediate response (e.g. having a submit button): https://doc.wikimedia.org/codex/main/style-guide/constructing-forms.html#field-type-usage In that case, we should switch to checkbox for forms. I can file up a follow-up issue for adapting checkbox. This is not a blocker for this PR. |
|
Code review PR: #848 |
…+ specs Follows-up to #837 Three follow-ups surfaced during code review of #837: - `PropertyDefinitionDeserializer` was dropping `default: false`. The truthy check in `propertyDefinitionFromJson` discarded any falsy default (`false`, `0`). Pre-existing, but #837 was the first PR with demo data that exercises it (`Everything.json` ships `boolean (default false)`). Replaced with an explicit `undefined`/`null` guard and added regression tests for the false boolean, zero number, and null cases. - `public-api.ts` was missing the three Boolean Vue components while every other property type re-exports its `*Display`, `*Input`, and `*AttributesEditor`. Added them for parity. - Added specs for `BooleanInput`, `BooleanDisplay`, and `BooleanAttributesEditor` to lock down the current behavior of these components against future regressions. Two design concerns from the review are deliberately left as-is because they conflict with #837's explicit "a boolean is never 'unset'" choice and the deferred "hide `Require a value` for Boolean" follow-up referenced in the #837 description: `BooleanInput.getCurrentValue()` returning `BooleanValue(false)` for an untouched input with `modelValue === undefined`, and the unreachable `required && value === undefined` branch in `BooleanType.validate()`. Raising them properly should pair with that follow-up since both touch the same per-type opt-out hook. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
I'll do a follow-up checkbox version for this property so we can compare. I suppose it is generally a good idea to follow the Codex usage guidelines. But my understanding of that explanation then is that our Schema Editor should also use checkboxes, since the changes are non-instant and require a save button. My impression is also that "non-instant" includes dynamic form element changes, but which do not actually persist and update the global UI (as opposed to the form). Not 100% confident, though. Swapping all toggle switches to checkboxes might be trivial, but also seems like unnecessary change right now. |
Codex's ToggleSwitch usage guideline says: Use the ToggleSwitch component only where an instant change in the user-interface based on their assigned action is intended. For non-instant selections and selection groups, use Checkbox instead. BooleanInput is the value editor for boolean properties, used in two non-instant contexts: - Subject editor: the value lands in a form gated by Save. - Schema editor's "Initial value" control: also lives inside the property-definition form, gated by Save. Both fit the "non-instant selection" case, so Checkbox is the guideline-correct widget. Swap CdxToggleSwitch to CdxCheckbox in BooleanInput.vue; same :model-value / @update:model-value wiring, same BooleanValue(true/false) emission shape, same default-to-false for undefined / wrong-type input. Field labelling is shaped to fit both call sites: - The CdxCheckbox's inline label is the property's own name (e.g. "Is public"). This is what the subject editor showed before the swap and what users see when they toggle the value. - The CdxField #label heading shows the caller-supplied props.label, but only when it differs from the property name. The schema editor passes "Initial value" so the heading renders and clarifies what the bare checkbox at the bottom of the property-definition form represents (the default for new subjects, not a value on the property itself). The subject editor passes the property name as the label, so the heading would just repeat the inline checkbox label; suppressed. - :optional is not set on the CdxField, because a Boolean value is always defined, so an "(optional)" affordance would be misleading. A short template comment documents both the heading-rule and the :optional omission so they don't read as oversights. Tests assert against CdxCheckbox (not CdxToggleSwitch), pin the inline-label-is-the-property-name behaviour, and cover both heading branches (shown when label differs from property name; hidden when they match). Behavioural assertions (modelValue prop binding, emit on update, BooleanValue emission, default-to-false, type-mismatch fallback, external-modelValue reactivity, getCurrentValue) are unchanged from PR #837. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Codex's ToggleSwitch usage guideline says: Use the ToggleSwitch component only where an instant change in the user-interface based on their assigned action is intended. For non-instant selections and selection groups, use Checkbox instead. BooleanInput is used in two non-instant contexts: - Subject editor: the value lands in a form gated by Save. - Schema editor's "Initial value" control: also lives inside the property-definition form, gated by Save. Both fit the "non-instant selection" case, so Checkbox is the guideline-correct widget. Local to BooleanInput.vue: same :model-value / @update:model-value wiring; the toggle's :align-switch and :label props are dropped (no Checkbox equivalents), the label text and optional description icon move into the Checkbox default slot. No data-shape change: BooleanInput still emits BooleanValue(true/false) on change, still renders checked iff modelValue.boolean === true, and still defaults to false for undefined / wrong-type input (the "Boolean is never unset" choice from PR #837). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Boolean property: use CdxCheckbox instead of CdxToggleSwitch Codex's ToggleSwitch usage guideline says: Use the ToggleSwitch component only where an instant change in the user-interface based on their assigned action is intended. For non-instant selections and selection groups, use Checkbox instead. BooleanInput is used in two non-instant contexts: - Subject editor: the value lands in a form gated by Save. - Schema editor's "Initial value" control: also lives inside the property-definition form, gated by Save. Both fit the "non-instant selection" case, so Checkbox is the guideline-correct widget. Local to BooleanInput.vue: same :model-value / @update:model-value wiring; the toggle's :align-switch and :label props are dropped (no Checkbox equivalents), the label text and optional description icon move into the Checkbox default slot. No data-shape change: BooleanInput still emits BooleanValue(true/false) on change, still renders checked iff modelValue.boolean === true, and still defaults to false for undefined / wrong-type input (the "Boolean is never unset" choice from PR #837). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * BooleanInput: field heading and inline label match the call site Shape field labelling to fit both call sites: - Inline checkbox label is the property's own name (e.g. "Is public"). This is what the subject editor showed before the swap and what users see when they toggle the value. - The CdxField #label heading shows the caller-supplied props.label, but only when it differs from the property name. The schema editor passes "Initial value" so the heading renders and clarifies what the bare checkbox at the bottom of the property-definition form represents (the default for new subjects, not a value on the property itself). The subject editor passes the property name as the label, so the heading would just repeat the inline checkbox label; suppressed. - :optional is not set on the CdxField, because a Boolean value is always defined, so an "(optional)" affordance would be misleading. A short template comment documents both the heading-rule and the :optional omission so they don't read as oversights. Tests grow by two cases pinning both heading branches (shown when label differs from property name, hidden when they match). The fixture now sets a stable property name "Is public" so the inline label has a meaningful assertion target. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 participants
Fixes #703
Summary
Adds a new
booleanproperty type for true/false values, following the established core property type pattern (most recently the select type, #711).BooleanValueand theValueType::Booleandeserialization path already existed in both PHP and TS; this PR adds the property-type wrapper, definition, UI, and registration.Schema JSON format:
{ "type": "boolean" }. No type-specific attributes;defaultmay betrue,false, ornull.Screenshots
BooleanAttributesEditoris intentionally empty (nothing renders between "Require a value" and "Initial value"); the initial-value control is the sameCdxToggleSwitchused in the subject editor.Is public · Boolean · No · Yesrow confirms PHP serialization of the Boolean property and its default round-trip and render.BooleanInputvalue editor. "Is public" rendered asCdxToggleSwitchon the ACME Inc subject form, currently on.BooleanDisplay. The infobox shows Is public: Yes after toggling and saving (full PHP/Neo4j round-trip).Design decisions
boolean(notcheckbox/toggle): it names the data, not a widget, so the UI can change without a schema migration.BooleanInputalways emits aBooleanValue, so a boolean is never "unset"; this matches checkbox/toggle semantics, and the input renders as a single inlinelabel [switch]row matching the schema editor'sRequire a valuerow. One residual cosmetic: the schema editor's Require a value switch still renders for Boolean properties because it's owned by the sharedPropertyDefinitionEditorchrome rather than gated per type. It has no effect on Boolean validation (the toggle always satisfiesrequired), so it reads oddly but is harmless. Hiding it cleanly would need a small per-type opt-out hook onTypeSpecificComponentRegistryorBasePropertyType; deferred as a follow-up so the same hook can serve any future always-has-a-value types.Test plan
BooleanPropertyTest: serialization round-trips, non-boolean default rejected); full suite 1032 tests green.Boolean.spec.ts: type, factory, validation); full suite 875 tests green.===to!==).🤖 Generated with Claude Code