Conditional statement not working for form using initialValues prop of FormRenderer

[singhnitin01]

I found one issue where the form has initialValues set using prop of FormRenderer and I'm using clearOnMount and initializeOnMount as true for all the fields. Now when I go to some other subForm and come back to the first subForm, all the fields get their initialValues set but it fails to show fields based on radio button condtions even though radio button is set to the expected initial value.

Sharing an example replicating the issue: https://stackblitz.com/edit/ccpsrt?file=schema.js,index.js

In example, you can see the data in last text-field for the first time. But when you select another radio button (form1 suppose) and then come back to form2, last text-field won't come which should be there based on radio button selected condition.

[Hyperkid123]

@singhnitin01 I think we are dealing with some race conditions. I'll try to give it a look ASAP.

[Hyperkid123]

My initial observation is that the condition does work when we set the initialValue directly to the filed in schema. But it is not working when set form the initialValues form prop.

[singhnitin01]

yes correct. I observed that. Just when we use initialValues, this doesn't work.

[Hyperkid123]

OK, I am gonna deep dive into the code and see what is the difference between these two.

[Hyperkid123]

OK, I see where the problem is and the line of code that can fix it. The problem is that I can't make a simple change to fix it. Part of the issue is why this error is happening is specific to the radio component and because it essentially registers multiple fields with the same name.

I think we have two options:

• automatically override the condition values source for components
• add a new prop to the condition that will let developers pick what source of condition values to use (I am inclined to this as the component types are only suggestions and the issue can happen in a custom radio component)

The problematic line is here: https://github.com/data-driven-forms/react-forms/blob/0f86d8bc04e7e89b4040db8d0d0f7b23da3c4d3c/packages/react-form-renderer/src/form-renderer/condition.js#L36

Specifically the values variable. We are building this object gradually based on the condition triggers (fields that affect the condition rule). Ass I said, the issue is that the radio button is a little bit special and each option registers itself as a new filed with the same name. Problem is that the condition is evaluated before the final radio value is set within the context.

If we source the data from the formOptions.getState().values we don't have the issue. But we will re-introduce other issues with async values and performance-based issues for every other component type.

So my suggestion would be to introduce a new Condition prop. Called something like, valuesSource that would default to the triggers, but with the option to choose formState. That should fix up this particular issue and not introduce any regressions.

@singhnitin01 what do you think?

[singhnitin01]

@rvsia could you suggest here. I will have to dig into this.

[Hyperkid123]

@singhnitin01 Wondering if this issue was in any way related to: https://github.com/data-driven-forms/react-forms/issues/1385

I will try to reproduce it again with the latest build.

[singhnitin01]

Not sure. But in my case parent is mostly above the child fields. @Hyperkid123

[Hyperkid123]

@singhnitin01 It's not related. I am publishing a fix now. I am just finishing tests.

[singhnitin01]

Thanks alot.

[rvsia]

:tada: This issue has been resolved in version 3.20.12 :tada:

The release is available on

• react-form-renderer (@latest dist-tag)

• ant-component-mapper (@latest dist-tag)

• blueprint-component-mapper (@latest dist-tag)

• carbon-component-mapper (@latest dist-tag)

• mui-component-mapper (@latest dist-tag)

• pf4-component-mapper (@latest dist-tag)

• suir-component-mapper (@latest dist-tag)

Data-Driven-Forms.org!

[singhnitin01]

Thanks @Hyperkid123 and @rvsia