Allow to cast a field to a specific type (e.g. when working with dynamic schemas where the actual type can not be inferred)

[katywings]

Is

If the schema is generated during runtime, you currently do not have a built-in way to help the editor infer the correct types.

Correct: the schema is inside the code, so the editor has no issues to infer the types:

Wrong: the schema was generated, so the editor infers a Strudel of all possible types:

Should

There should be ways, or atleast one way to get the correct field props for the particular situations. E.g. maybe a builtin CustomFieldStore helper type that returns the proper FieldStore type for the specified schema:

const numberSchema = v.number();

type CustomFieldStore<T extends v.GenericSchema> = FieldStore<
  v.ObjectSchema<{ s: T }, undefined>,
  ['s']
>;

<Show when={dbField.type === 'number'}>
  <Field of={loginForm()} path={[dbField.name]}>
    {(field_) => {
      const field = field_ as CustomFieldStore<typeof numberSchema>;
      type V = typeof field.input;

      return (
        <TextInput
          {...field.props}
          input={field.input}
          errors={field.errors}
          type="number"
          label={label()}
          required
        />
      );
    }}
  </Field>
</Show>

Result:

Extras

• StackBlitz including a server-generated schema example: https://stackblitz.com/edit/formisch-playground-solid-wlnfcmcj?file=src%2Froutes%2Flogin%2Findex.tsx
• This feature request stems from the chat at https://bsky.app/profile/katywings.bsky.social/post/3mesribexgk2e

[fabian-hiller]

I understand the issue, but there is no clean solution. We expect a typed schema and let the type of the schema flow through the entire form. I recommend waiting for more feedback from other developers before making improvements.

Here is how I understand the issue: Formisch is fully typed, and the raw type of the schema flows through the entire form API. If you don't know the exact schema type of the form but you know the input or output TypeScript type, we might want to give users the option to specify the type of a field in a clean way.

[katywings]

What do you understand as clean solution? "There is no clean solution" sounds very absolute, have you already thought about all possible solutions 😅?

That said, if I understand you correctly CustomFieldStore is not a clean solution in your eyes?

How about just letting the user set an explicit field schema type via prop:

<Show when={dbField.type === 'number'}>
  <Field of={loginForm()} path={[dbField.name]} schemaType={numberSchema}>
    {(field) => {
      return (
        <TextInput
          {...field.props}
          input={field.input}
          errors={field.errors}
          type="number"
          label={label()}
          required
        />
      );
    }}
  </Field>
</Show>

[fabian-hiller]

Hey, I am sorry for being so unspecific with my last message. The "issue" is that the root schemas flows thought our entire API. Therefore, you cannot easily overwrite the generics with simple and user friendly types.

For example this is the type of the <Field> component:

export function Field<
  TSchema extends FormSchema,
  TFieldPath extends RequiredPath,
>(props: FieldProps<TSchema, TFieldPath>): JSX.Element;

Providing types that allows you to define the generics with simple types (and not a complex schema type) forces us to duplicate these functions. Clean would be to allow the user to write:

<Show when={dbField.type === 'number'}>
  <Field<YourCustomType> of={loginForm()} path={[dbField.name]}>{...}</Field>
</Show>

[katywings]

Maybe I am one of the more pragmatic devs after all (my POs usually say I am too perfectionist 😂), but if <Field<YourCustomType> is the only clean solution in your eyes, yet it is not a possible solution because of the way how generics work in TS, whats the value of it being clean if it cannot actually be implemented 🙈?

Whats more valuable from a business sense, the solution that solves the use case and can actually be implemented, or the one that would be perfect in a perfect world, but is not possible?

[fabian-hiller]

Yes, I agree. We should make it possible somehow. Simplest solution is probably we create a copy of the FieldStore type optimized for this case.