Host Components Helpers (FieldHost, SubmitHost, FormHost)

useFormBridge() returns components that are closed over the current runtime: form.Form, form.Form.Submit, and every form.fields.* component are functions created *inside* the hook so they can carry the form's state, validation pipeline, and analytics hooks without a context lookup.

That design is great for DX, but it means their component reference is not stable across renders - re-mounting the parent, re-running the hook, or switching to a new schema produces brand new component functions. Styling libraries that use styled(Component), emotion.styled(Component), panda.cva(Component), etc. all assume you pass them a module-level component whose identity never changes. If you pass them a freshly-created function on each render, you get:

• A new styled component generated on every render (wasted work, potential memory churn).
• Broken React.memo / useMemo optimizations downstream.
• Occasional remounts of the styled element, which resets focus, selection, and uncontrolled state.
• Confusing DevTools entries that change names on every render.

Host helpers are the fix. They are defined once at the module level, their identity is stable forever, and they render the real runtime component via a prop. You get all the benefits of schema-driven fields *and* all the ergonomics of wrapper-based styling libraries at the same time.

Reach for host helpers when both of the following are true:

• You are styling FormBridge with a wrapper-based library: styled-components, styled-components/native, emotion (styled()), panda (cva(Component)), stitches, linaria, goober, or anything else that expects a stable component reference.
• You want to keep using the generated components (form.Form, form.fields.*, form.Form.Submit) instead of dropping down to fieldController() or field.custom().

You do not need host helpers when:

• You are styling with CSS classes, Tailwind, CSS Modules, inline style props, or the built-in globalDefaults options - those work directly on the generated components.
• You already need to replace the whole field renderer (custom trigger, modal picker, composite widget). In that case, fieldController() gives you more control.
• You are writing a brand new field type that no builder covers. In that case, field.custom() is the right tool.

In short: host helpers are the bridge between FormBridge's schema-driven runtime and styling libraries that require module-level components. They add zero behavior; they only fix identity.

Each host helper accepts its own special prop plus every prop of the underlying component. Nothing is filtered - FormBridge just calls React.createElement with the component you passed in and spreads the rest of the props onto it.

That means the native platform attributes of the wrapped runtime component stay available too. For example, <FormHost form={form.Form} method="post" aria-label="Checkout" /> works on web, and <SubmitHost submit={form.Form.Submit} testID="checkout-submit" /> works on native.

Because the host just forwards, you can combine styled(FieldHost).attrs({ classNames: { … } }) with inline props at render time - the two are merged the way they would be on the raw field.

• You must pass the runtime component explicitly. Host helpers do not read from context - <FieldHost field={form.fields.email} /> is mandatory. There is no "current field" fallback.
• Define the styled host at module scope, never inside a component. Redefining const StyledField = styled(FieldHost) on every render brings back the exact identity problem the helpers were designed to solve.
• Keep the field / submit / form prop reference stable across renders. form.fields.email from the same useFormBridge() call is stable within a single render tree; do not recreate the hook conditionally above it.
• Host helpers do not work for fully custom UI. If you need to replace the markup entirely, use fieldController(). Host helpers only help you *wrap* the generated components.
• Field override props still apply. Inline-styling with props like classNames, styles, inputProps (or with globalDefaults) keeps working inside a host-wrapped component; wrapper styles compose on top of - not in place of - FormBridge's own rendering.