Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When passing form names dynamically, the inner component still shows the previous state #2303

Closed
thanhvuong opened this issue Dec 17, 2016 · 10 comments

Comments

@thanhvuong
Copy link

thanhvuong commented Dec 17, 2016

We're running into the same problem (but I'm on 6.3.2) posted by @just-boris on #603 (comment)

Got this problem with the latest release 6.2.0. I am passing the form name dynamically, but the inner component still shows the previous state.

See the example: http://www.webpackbin.com/Vkwc8SZzM
When you are switching current form to "Form B", it is not possible to edit input value. It's happening because all redux-form actions are still bound to the previous form name. After some investigation, I have figured out, that bindDispatchToProps is not called after form change. Any ideas how to work around this?

@babsonmatt
Copy link

Looks like the form changes but the onChange still uses the previous form name

@hbelen
Copy link

hbelen commented Jan 9, 2017

We have bumped into the exact same problem on 6.4.1. We're working on a form-heavy application which uses schema files to describe which input the API endpoints accept. It made sense to create a form generator which consumes these schema's. Everything works smoothly, except for this. Were you able to wire everything up correctly, @thanhvuong?

@EduardoAC
Copy link

EduardoAC commented Jan 9, 2017

It happens the same to me.

I tested my implementation with two different pages, that means two different stateless components used to render instances of the same form and it works fine.

I run into this error when I try to change the form with form (key name) and fields values so when it gets the new props in my component, it contains different values that should force to re-render the form by changing the state with my own action.

Therefore, it seems the current form and the state is lost.

NOTE: One thing to keep in mind, it's that the fields inside of the form get updated in the current instance

@realbugger
Copy link

Any update on this bug, or workaround figured out?

@apendua
Copy link

apendua commented Mar 23, 2017

So I have found the following workaround:

<div>
  {[
    <MyForm key={form} form={form} />
  ]}
</div>

This works because using array item with varying key forces React to unmount/mount that component.

@just-boris
Copy link
Contributor

@apendua, actually I did the same, but you don't even need to create an array:

<div>
  <MyForm key={form} form={form} />
</div>

This will work as well.

@apendua
Copy link

apendua commented Mar 23, 2017

@just-boris I didn't know about that. Thanks!

@EduardoAC
Copy link

@apendua we tried that option in multiple ways.

It did overwrite the fields but it didn't delete the previous state of the form in redux so we land in weird situations where the form lost consistency and stop working.

we are using dynamically pass the option key an form by a selector in the same container component. something like

  1. render the page (contains already a form)
  2. select option "register data for address"
  3. pass the new fields and key to the component
  4. Render the new form fields but keep the same original form in the state updating only the fields.

Personally, I think this is not solve, we needed it to use react-router to re-render the whole page when we select the form so we have now multiple forms files rather than an unique file which change the content.

@gustavohenke
Copy link
Collaborator

Because this issue saw almost no activity for a few months, I'm closing it.

@lock
Copy link

lock bot commented Dec 7, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Dec 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants