- Removed custom form reducers in favour of redux-form (updateField(), addForm(), etc)
- Storing 'state' in schema reducer to avoid a separate forms reducer tree (no longer needed for other use cases). This means 'state' is only the "initial state", any form edits will be handled by redux-form internally in the 'reduxForm' reducer namespace
- Removed componentWillUnmount() from <Form> since there's no more reducer state to clean up (removed formReducer.js), and redux-form handles that internally
- Removed isFetching state from <FormBuilder> since there's now a props.submitting coming from redux-form
- Improved passing of "clicked button" (submittingAction), using component state rather than reducer and passing it into action handlers (no need for components to inspect it any other way)
- Hacky duplication of this.submittingAction and this.state.submittingAction to avoid re-render of <FormBuilder> *during* a submission (see https://github.com/erikras/redux-form/issues/1944)
- Inlined handleSubmit() XHR (rather than using a redux action). There's other ways for form consumers to listen to form evens (e.g. onSubmitSuccess passed through <FormBuilder> into reduxForm()).
- Adapting checkbox/radio fields to redux-forms
Need to send onChange event with values rather than the original event,
see http://redux-form.com/6.1.1/docs/api/Field.md/#-input-onchange-eventorvalue-function-
- Using reduxForm() within render() causes DOM to get thrown away,
and has weird side effects like https://github.com/erikras/redux-form/issues/1944.
See https://github.com/erikras/redux-form/issues/603#issuecomment-176397728
- Refactored <FormBuilderLoader> as a separate container component which connects to redux and redux-form. This keeps the <FormBuilder> component dependency free and easy to test. It'll also be an advantage if we switch to a GraphQL backed component, in which case the async loading routines will look very different from the current <FormBuilderLoader> implementation
- Refactoring out the redux-form dependency from FormBuilder to make it more testable (through baseFormComponent and baseFieldComponent)
- Passing through 'form' to allow custom identifiers (which is important because currently the schema "id" contains the record identifier, making the form identifier non-deterministic - which means you can't use it with the redux-form selector API)
The URL to request the schema representation is the unique identifier.
We can't default to $request->getURL() since that's different for form submissions.
The schema.schema_url key is redundant, since the identifier is already contained on the top level 'id' key.
Keeping schema_url in a schema itself makes it less portable, particularly once we transition into
generic schemas which are not reliant on a particular record context (that's only contained in the schema_url)
This also fixes the issue of form schemas not refreshing after submit,
e.g. when form fields are added or removed.
Created a generic DataObject FormFactory interface that can be substituted in place of getCMSFields. Different FormFactories can depend on different kinds of context, such as
'Record' or 'Controller' - it's the responsibility of the code calling the factory to interpret and
supply this context.
The expected use-case is that rather than overriding getCMSFields(), developers can
change CMS UIs by manipulating the FormFactory associated with the given DataObject.
This is an experimental UI and may change before 4.0 stable is released.
