onSubmit cancels when button onClick causes re-render #1944

chillu · 2016-10-10T23:40:19Z

Hello there! We're planning to use redux-form in our CMS UI (silverstripe.org), which gets powered by a JSON form schema. This means we've got a "builder" class which dynamically creates a form from the schema definitions (and passes it through reduxForm() on render()).

I'm stuck on a bug on how to handle a "loading indicator" on the clicked button in this particular configuration. I'm rendering actions in the same component which performs reduxForm(), and pass them through the reduxForm() layer down to the actual form rendering. A button onClick() causes a setState() in this component, which changes actions and triggers a re-render.

I would expect my onSubmit handler to be fired after the onClick completes (and doesn't explicitly cancel the event), but instead it re-renders the form and defaults to the standard <form> submission behaviour, causing a page reload.

An isolated example: https://gist.github.com/chillu/b102b4ebea3655db0703f95db9d24511

If you add these classes to any of the examples/ in this repo you should get it to build. Comment out the setState() invocation to verify it works without it. I've removed a bit of noise like hot reloading.

We can't easily move the action generation one level down (inside the component which is wrapped in reduxForm()) - so the re-render seems like a necessary one. But it shouldn't fluke out of the onSubmit handling either way, right? While I could move the submitting state into the button component itself, I need to unset it based on factors outside of its control - and the only way to get those through is via React props on the containing form which causes a re-render.

The text was updated successfully, but these errors were encountered:

chillu · 2016-10-11T00:11:53Z

Changing to an async setState() via setTimeout() fixes this, but feels a bit like a hack. If only a few parts of the React DOM tree within the <form> tag change, shouldn't the virtual DOM library leave the <form> tag itself in place, and just replace an <input> DOM element inside the existing one? Sorry, I'm hitting the limits of my knowledge around how React manifests updates in the DOM.

handleButtonClick(e) {
    const name = e.currentTarget.name
    setTimeout(() => this.setState({ submittingButton: name }), 100)
  }

…#5524) - 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 redux-form/redux-form#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()).

- Using reduxForm() within render() causes DOM to get thrown away, and has weird side effects like redux-form/redux-form#1944. See redux-form/redux-form#603 (comment) - 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)

…#5524) - 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 redux-form/redux-form#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()).

- Using reduxForm() within render() causes DOM to get thrown away, and has weird side effects like redux-form/redux-form#1944. See redux-form/redux-form#603 (comment) - 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)

…#5524) - 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 redux-form/redux-form#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 redux-form/redux-form#1944. See redux-form/redux-form#603 (comment) - 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)

- 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 redux-form/redux-form#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 redux-form/redux-form#1944. See redux-form/redux-form#603 (comment) - 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)

danielrob · 2017-08-06T21:20:52Z

@chillu this one looks juicy! Before I take a look - would you mind just firing a quick update since it's been 10 months?

chillu · 2017-08-08T08:44:57Z

Sorry I'm on leave this week, will have a look when I'm back next week :)

On Sun 6. Aug 2017 at 23:20, Daniel Robinson ***@***.***> wrote: @chillu <https://github.com/chillu> this one looks juicy! Before I take a look - would you mind just firing a quick update since it's been 10 months? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1944 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGxsZxVR9_S7wUhLt3tne32aGFK7yRSks5sVi43gaJpZM4KTGOR> .

-- Ingo Schommer | Solutions Architect SilverStripe (http://silverstripe.com) Mobile: 0221601782 Skype: chillu23

jpaas · 2017-10-05T00:34:30Z

I'm seeing the same behavior on a react native app with a simple form with a Field using TextInput as the component and a button. When the input has focus and I click the button, the field is blurred and the validations are run, but the button's onPress is never called.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

onSubmit cancels when button onClick causes re-render #1944

onSubmit cancels when button onClick causes re-render #1944

chillu commented Oct 10, 2016 •

edited

Loading

chillu commented Oct 11, 2016

danielrob commented Aug 6, 2017

chillu commented Aug 8, 2017 via email

jpaas commented Oct 5, 2017

onSubmit cancels when button onClick causes re-render #1944

onSubmit cancels when button onClick causes re-render #1944

Comments

chillu commented Oct 10, 2016 • edited Loading

chillu commented Oct 11, 2016

danielrob commented Aug 6, 2017

chillu commented Aug 8, 2017 via email

jpaas commented Oct 5, 2017

chillu commented Oct 10, 2016 •

edited

Loading