A general-purpose input component for most Values. c-input does not have much functionality of its own - instead, it delegates to the right kind of component based on the type of value to which it is bound. This includes both other Coalesce Vuetify Components as well as direct usages of some Vuetify components.

All attributes are passed through to the delegated-to component, allowing for full customization of the underlying Vuetify component.

A summary of the components delegated to, by type:

Any other unsupported type will simply be displayed with c-display, unless a default slot is provided - in that case, the default slot will be rendered instead.

When bound to a ViewModel, the validation rules for the bound property will be obtained from the ViewModel and passed to Vuetify's rules prop.



Typical usage, providing an object and a property on that object:

<c-input :model="person" for="firstName" />

Customizing the Vuetify component used:

<c-input :model="comment" for="content" textarea solo />

Binding to API Caller args objects:

    for="newName" />

Or, using a more verbose syntax:

    for="Person.methods.setFirstName.newName" />

Binding to Data Source Parameters:

<c-input :model="personList.$dataSource" for="startsWith" />

Usage with v-model (this scenario is atypical - the model/for pair of props are used in almost all scenarios):

<c-input v-model="person.firstName" for="Person.firstName" />


for?: string | Property | Value

A metadata specifier for the value being bound. One of:

  • A string with the name of the value belonging to model.
  • A direct reference to a metadata object.
  • A string in dot-notation that starts with a type name.
model?: Model | DataSource
An object owning the value that was specified by the for prop. If provided, the input will be bound to the corresponding property on the model object.
value?: any
If binding the component with v-model, accepts the value part of v-model.


Used to display fallback content if c-input does not support the type of the value being bound. Generally this does not need to be used, as you should avoid creating c-input components for unsupported types in the first place.