Formless fields

What

Need to consider a formless usage of field components.

Why

Right now when a field component is rendered and is unable to find any ancestor Form, it will throw an error during the record registration. This may be confusing for the beginning developers.

However, it is also reasonable to insist to wrap fields in Form. Fields compose a form, so there must be a form. This suggestion requires discussion.

Specification

1. General statements. a) A field is considered formless when it doesn’t have a wrapping <Form> component.
2. Technical statements. a) A formless field cannot access fields and form within any callback/handler methods. b) A formless field cannot access fields and form in any validation resolvers. c) A formless field behaves as a plain input field. That implies, it is uncontrolled by default, and can be made controlled by providing a value prop and a change handler function. d) (???) A formless field can still accept field enhancers. e) A formless field doesn’t benefit from any form behaviors (serialization, validation, etc.).

[kettanaito]

Hi, @nickensoul. Thanks for the kind words! Let me update you.

Technical background

The biggest task here is to replace the Form as the event source hub. At the moment the Form component establishes per-instance event emitter, and subscribes to certain events with handlers. Field component wrapped in createField communicates back to the parent Form via form’s event emitter to propagate such events as mounting/unmounting, value change, focus, or blur.

I would say that from the technical perspective a solution to support formless fields is somewhat clear. It would be good to implement (or prepare for) formless fields under #324. I’m currently working on #354, which improves event handlers that would grant less control to the Form, and more to the events.

What now?

I understand both a desire to use a form element without a wrapping Form, and a conceptual idea behind a form input (to gather data for a form). Nevertheless, I still think that formless fields is worth implementing, but I would also encourage developers to expect less functionality from a formless field.

This implementation is on the roadmap, but I would put #324 and #232 as the highest priority.

Functionality limitations

• A formless field cannot be submitted (that contradicts both forms design and internal implementation)
• A formless field would require to inherit validation schema and messages from the FormProvider, or via custom HOC (to be discussed)
• A formless field cannot have reactive props, as they reference fields under a single form domain

[kettanaito]

Update

It has just occurred to me, that it is possible to understand whether the field is formless on the createField high-order component level.

That way, in case of formless fields, HOC could act as a field’s state accumulator, a replacement for Form in terms of field-form communication. This way field component remains as is, it keeps communicating up as is, as if there is always a form. Instead, createField HOC gets smarter in case of formless fields.