Are lazy fieldComponents worth it?

[literalpie]

The composition docs recommend adding components using the fieldComponents value, and making the components lazy to mitigate bundle-size issues that would be caused by including all components in the form object.

I'm really questioning if this is worth the trouble. If you have lazy components conditionally shown in your form, this can cause your suspense boundary to trigger when they are first shown. This can be improved by adding "smaller" suspense boundaries, but that's extra work and it still seems to be non-ideal UX.

The lazy components also cause issues for us in unit tests.

It seems like the main benefit of the fieldComponents pattern is autocomplete and guaranteeing that the field context is available, but this doesn't seem like it's worth the trouble.

Have others run into problems with this pattern? Has anyone had success bypassing the pattern and importing field components normally?

[apoorva-01]

Lazy isn't part of the pattern, it's an optional bolt-on. The composition docs pass components straight in (fieldComponents: { TextField } with a plain import) and only bring in lazy way down in the "Tree-shaking" section, framed as a thing you reach for when you've got hundreds of field components and don't want them all in every bundle. If that's not your problem, skip it.

So yes, import them normally. You lose nothing except code-splitting you weren't benefiting from, and you drop the Suspense-on-first-render jank and the test headaches along with it. The real value of createFormHook/fieldComponents is the DX: typed field context (useFieldContext<string>()) plus withForm/withFieldGroup for reusable chunks without hand-threading form and field props everywhere. None of that needs lazy.

If you do have a couple of genuinely heavy fields worth splitting out, make just those lazy and keep the rest eager, rather than lazying the whole set. Then only that handful needs await findBy* in tests, and the common path stays synchronous.