-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Labels
help wantedExtra attention is neededExtra attention is needed
Description
Background
Architecture TL;DR - For each form field, you define an object literal that is the "fieldConfig", then pass an array of related fieldConfigs to the RenderGroup component. Which creates FieldGroup components dynamically here - https://github.com/CalderaWP/caldera-components/blob/master/src/components/RenderGroup.js#L63
FieldGroup is responsible for the wrapping element, which contains, a label and message component, and FieldInner and kind of a mess of logic to figure out what the actual form field component is and how to pass props. The message component is for validation messages.
I am also concerned we have to much nesting here: RenderGroup -> FieldGroup -> FieldInner -> Input or Select or MagicSelect.
Requirments
- Please see contributing guide for general requirements for submitting a pull request.
- Ability to add new possible fields. For example, my Caldera Forms add-on could add new types of fields to the system. Note, state management is NOT in scope for this module, we need a prop that can be updated later that provides:
- Field type identifier
- Field type specific field validation
- After this is closed, we will add the capability in @caldera-forms/state to manage that prop.
- Location for label prop (above, left, right, below input)
- Existing tests that cause a FieldGroup to be used still pass with the same props.
- The concerns handled
fieldInnerfunction inFieldGroupand theFieldInnercomponent should be separated so that thefieldInnerfunction inFieldGrouphas the responsibility of renderingFieldInnerwhich has the responsibility of rendering the form field. Or even better simplify by removing one. - Update docs to explain changes.
Metadata
Metadata
Assignees
Labels
help wantedExtra attention is neededExtra attention is needed