Should we bring back native element prop getters?

[edmundhung]

Context

In v1, Conform had built-in prop getters like getInputProps() and getSelectProps() for native HTML elements. The new configureForms API takes a different approach with extendFieldMetadata: you define exactly what props you need for your components, and they become available on the field metadata.

const forms = configureForms({
  extendFieldMetadata(metadata) {
    return {
      get inputProps() {
        return {
          id: metadata.id,
          name: metadata.name,
          defaultValue: metadata.defaultValue,
        };
      },
    };
  },
});

// Then use it like: fields.email.inputProps

The reason I moved away from built-in getters is that in practice, people often spread them onto UI library components, not native elements. UI libraries have their own naming conventions, and TypeScript won't warn about extra props when spreading. They just silently pass through.

The feedback

In #1131, someone raised a few good points:

• Native HTML elements are stable and will outlast any UI library. They won't change their API. Having built-in support for them seems reasonable.
• With extendFieldMetadata, you need to know which validation attributes apply to which element (e.g. min/max for <input> but not <select>). Built-in getters handled this for you.
• Projects can't automatically benefit from new metadata properties in future Conform updates. You'd have to update your config manually.

My thoughts

I understand the friction. You shouldn't have to think about which validation attributes apply to which element type. That's something the library can handle for you.
That said, if both nativeInputProps and custom inputProps exist on metadata, it could confuse developers who just build forms but didn't set up the config. "Which one should I use?"

One idea I'm considering is a CLI that scaffolds the config for you:

npx conform react --ui shadcn --schema zod

It would generate a forms.ts with the full extendFieldMetadata setup for your chosen UI library. We already maintain examples for shadcn, chakra, material-ui, etc. This would just make them easier to use as starting points.

You'd own the code and can customize it, but you get a working config without having to think about which attributes apply to which element. The setup is a one-time thing, and most projects don't have that many input types.

If we bring them back

If we do bring back native prop getters, there are two main approaches:

1. Always available on metadata

   <input {...fields.email.nativeInputProps} />
   <select {...fields.category.nativeSelectProps} />

   Simple and discoverable, but could be confusing alongside custom props from extendFieldMetadata.

2. Separate helper functions (like v1)

   <input {...getInputProps(fields.email)} />
   <select {...getSelectProps(fields.category)} />

   Clear separation from custom metadata, but a different API style.

Open questions

• Do you want the props getter back?
• Would a CLI that scaffolds the config for you solve this, or is there value in having it built-in?
• If we add built-in native prop getters alongside custom metadata, do you think it would be confusing?

Would love to hear your thoughts.

[transparent-citizen]

Thank you very much for the detailed write-up!

Do you want the props getter back?

Adding to what's already been mentioned, another nuance worth mentioning is that React's <select multiple> will refuse to set the defaultValue and complain in the console if the defaultValue is not an array. So currently, if you need React-compatible <select> props, you have to differentiate these cases yourself.

const forms = configureForms({
	extendFieldMetadata(metadata) {
		return {
			get selectProps() {
				return {
					defaultValue: metadata.multiple // <---
						? metadata.defaultOptions   // <---
						: metadata.defaultValue,    // <---
					form: metadata.formId,
					id: metadata.id,
					name: metadata.name,
					required: metadata.required,
				} satisfies SelectProps;
			},
		};
	},
});

Such logic is best kept in a prop getter.

Would a CLI that scaffolds the config for you solve this, or is there value in having it built-in?

If a CLI emits code that users keep under version control, the users take ownership of their scaffolds, which allows them to modify the form configs. Future versions of Conform might add new props, but users who use a modified scaffold would then be faced with friction to keep their modifications in sync with the latest version of Conform's scaffold. Merging scaffolds tends to involve regenerating the scaffold to another file, diffing the new scaffold against the old user-modified scaffold, and then spend some time working out what needs to go where.

This could be avoided by creating boundaries that isolate library code from user code. Prop getters could achieve this and make updates smoother:

import { getTextFieldProps } from "@conform-to/react/future/material-ui";
import type { ComponentProps } from "react";
import type { TextField } from "@mui/material";

const forms = configureForms({
	extendFieldMetadata(metadata) {
		return {
			get textFieldProps() {
				return {
					...getTextFieldProps(metadata),
					variant: "filled"
				} satisfies ComponentProps<TextField>;
			},
		};
	},
});

If we add built-in native prop getters alongside custom metadata, do you think it would be confusing?

Code structuring (and docs, to a lesser degree) are very much key. Something like the code above, where you import UI-library-specific getters, should also be tree-shakable and help keep things structured. If the prop getters were all accessible through metadata (like metadata.muiTextFieldProps/metadata.nativeInputProps), I don't think that tree shaking could catch that. My guess is that they'd all get shipped to the user, even if none of them are used, since getters could be accessed dynamically at runtime, whereas module usage is statically analyzable at bundle time.

My conclusion

I believe that separate helpers promise the best DX, and also the fastest UX through smallest bundle size.

[mxp-qk]

Hey,

configureForm is a great addition! It is a very clean way to tailor conform fields to the UI library's specific needs. I rewrote all my component logic, ditching specific helpers (racTextFieldProps,racSelectProps,...) in favour of the custom getter, which is much cleaner and less error-prone.

Do you want the props getter back?

Built-in native props getters were useful, as sometimes the IU library version is not used, and going back to the native HTML element is required.

Keeping them separated seems cleaner, imo. The v1 API was great when no customisation was needed. It also leaves the possibility of writing a "custom native" getter anyway if it seems more appropriate.

const forms = configureForms({
  extendFieldMetadata(metadata){
    get racSelectProps () {
      // React aria components logic
    }
    get nativeSelectProps () {
      return getSelectProps(metadata)
    }
  }
})

Would a CLI that scaffolds the config for you solve this, or is there value in having it built-in?

I like the idea of built-in helpers for different UI libraries, but I am curious about what will be inside those helpers, as UI libraries are more and more headless, and component composition and props wiring are more and more up to the developer.

The maintained examples were a great addition to the documentation, providing a basis for building and adapting to the specificity of each code base, where v1 props getters were not enough. Built-in helper might not be relevant when UI library version brings a breaking change (for example, for the multi-selection in React Aria, here).

Listing the example in the configureForms JSDoc with a link to each library example could be useful.

If we add built-in native prop getters alongside custom metadata, do you think it would be confusing?

It might not be confusing with clear native naming convention, but the ability to override the getter configureForms smells like a footgun.