OmegaForm: use Vuetify v-number-input for number fields

[omegent-app]

Why

Schema-inferred number fields currently render v-text-field type="number" and coerce on write:

@update:model-value="(e: any) => {
 if (e || e === 0) {
 field.handleChange(Number(e) as any)
 } else {
 field.handleChange(undefined as any)
 }
}"

(OmegaInputVuetify.vue)

An HTML/Vuetify text field with type="number" emits strings (el.value). Number(e) is a write-boundary patch for that. Vue’s .number modifier does not fix it on a component (v-text-field only implements .trim). That type/runtime lie just bit scanner packing (MACS-SCANNER-313, scanner#2250).

Vuetify 4 already has v-number-input (modelValue: Number, empty → null). OmegaForm already infers type from meta.type — callers should not pass type="number".

Proposal

When inputProps.type === "number", render v-number-input instead of v-text-field. Keep v-slider for range. Bind a real number (or null/undefined for empty). Drop Number(e) as any.

Pass schema min/max through. Empty should match current handleChange(undefined) unless we document a null change.

If we should not

If v-number-input is the wrong control, document why in the OmegaForm docs (locale/grouping, empty vs 0, stepper UX, PrimeVue renderer parity, …). Right now there is no such note, so the text-field + Number(e) path reads as leftover, not a decision.

@MakhBeth — please take this: either land v-number-input, or write the “why not” next to the number renderer.

Context

• OmegaInputVuetify.vue (number / range branch)
• Type inference already lives in OmegaInternalInput (props.type else meta.type)

opened by Patrick Roza in chat thread Discord · Discord · T3

[MakhBeth]

Shipped: 4.0.0-beta.315 introduces v-number-input (#870), 4.0.0-beta.316 fixes the . vs , decimal separator input (#872).