[BUG] FormStateToRedux - Maximum update depth exceeded

[borm]

All forms with initial values

No nested input names

Original simple example - codesandbox
Original example with connected Container - codesandbox

Nested input names

Bug
Original example with connected Container and nested initialValues & input names - codesandbox

Fix
Original example with connected Container & Form and nested initialValues & input names - codesandbox

[erikras]

I'm sorry, but I'm not seeing that error when typing in the fields. Can you give me some steps to reproduce?

[erikras]

Yeah, that's one of the ones above. I clicked on them all. What do I have to do to recreate the error?

[borm]

https://codesandbox.io/s/1o2rn6yo7

[borm]

The code is updated

[borm]

fuck, something wrong in my example

[borm]

updated again

const ConnectedReduxContainer = connect((state) => ({
  state: getFormState(state, "example")
}))(Container);

[erikras]

Ooh!!! This was an interesting one!!

The Form component is only doing a shallow equals check on the initialValues prop to determine if it has changed. If it has changed, then it reinitializes the form, which, in turn, was dispatching the update action via the FormSpy. That's why it works if the initialValues are flat, but not if they are deep.

I think that it probably needs to do a deep equals check on initialValues, but for now you can work around it by not creating a new object of your initialValues every time the connected component rerenders. See lines 20-25:

Personally, I would not connect the container of the form to Redux in this way; I would only connect whatever particular deeper component needs that state. Makes sense?

[borm]

Oh, my initialValues depended from BackEnd, it`s cant be static

[erikras]

That's fine, as long as it's the same object coming from Redux or whatever is loading them. You just can't construct a new object when passing the prop.

That said, I will implement deep equals on the initialValues check.

[borm]

as example i can define initial values in component constructor, makes sense?

[erikras]

Yep. As long as the object is only instantiated when they actually change, you should be fine.

[borm]

when you planned fix it?

[erikras]

Yes, sorry. This week has been busy.

[erikras]

Okay, so deepEqual() is complicated. I wonder if we could allow an isEqual function to be passed in for initialValues checking....

[arthurdenner]

@erikras would you consider using react-fast-compare to compare initialValues instead of allowing an isEqual function? Seems like a good alternative to solve the problem and it's pretty small too.

[erikras]

Published fix in v3.6.6.

[erikras]

@arthurdenner My reasoning on going with a function prop is that most people won't need it, as most forms are not deeply structured, but to allow flexibility for those that are.

[arthurdenner]

@erikras Got it. Thanks for explaining it.

[lock]

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.