Setters after initializing values

[Ali-Zmn]

I remember there was a release on preventing setters to overwrite the initial values but I still have this issue! the weird part is that I can't reproduce it in codesandbox.
There is a setter in a sequence which does its job perfectly, then when I change the field and save the form, it will set it again! I checked the renders, it is all good until the last couple of renders and then suddenly it overwrites it! the fact that I cannot reproduce it outside my env pointed me that the problem may lay in my env but I have no clue why this is happening! If you have any insights please let me know.

[Hyperkid123]

@Ali-Zmn this might be a silly question but I have to ask. Do you have the latest version of the library installed?

If that is the case I guess it would not be possible to give us a peek at your env so we can debug it properly?

[Ali-Zmn]

Yes, I'm using the latest. Here is a peek of it
In the sequence, it sets the external traffic policy (in the networking tab) to local even if in the initial value I set it to Cluster! it is also true for Legacy Service Annotations.

[Hyperkid123]

OK, I think know what is wrong but not yet why. We check if the form was modified. IF it's not, we do not allow setters to trigger. Thing is, after some rendering I see the modified rule is true which then allows the setter to trigger. I will scan through your example and see why is that. It may take me a few days before I can take a deeper dive into it.

[rvsia]

I think the issue is that we check if the field is modified but we should rather check modifiedSinceLastSubmit in condition.js, it should be an easy fix but I won’t be able to check it before the next week.

react-forms/packages/react-form-renderer/src/condition/condition.js

Line 54 in c9b703a

const isFormModified = Object.values(formOptions.getState().modified).some(Boolean);

[rvsia]

^ @Hyperkid123

[rvsia]

Read more: https://final-form.org/docs/final-form/types/FieldState#modifiedsincelastsubmit

[Hyperkid123]

Yeah, I was thinking the same. There also might be an issue that the setters are not executed in batch. So the first condition unlocks the rest.

[Hyperkid123]

@Ali-Zmn We are just looking at your example and we have found the issue.

The good news is we can fix your example. If you remove the initializeOnMount from your schema version, the setters start to behave as they should.

    {
      component: "textField",
      name: "schemaVersion",
      initialValue: "1.1.0",
-     initializeOnMount: true,
      hideField: true
    }

So why is this happening? Due to final form limitations, we have to call the change method for fields with this flag. This will mark the for as modified, opening the gates for setters.

So you will have to set the value somewhere else. Preferably in your initial values object that you feed to the renderer.

The bad news is that we won't be able to properly solve the issue until we migrate to your custom state management library which is currently in progress.

[Ali-Zmn]

Thanks for debugging this. The example is fine by removing the initializeOnMount: true but my code still has the same issue even by removing all initializeOnMount: true!is there another flag with the same behaviour to call the change ?

[Hyperkid123]

Can you post the full schema? We should not require anything else.

[Ali-Zmn]

Thanks, @Hyperkid123 @rvsia, I think I got it resolved temporarily! I'm using redux as my state manager, and somehow connecting the store state directly to the form renderer was causing extra rerenders(still don't know why!) so I had to prevent rendering on different scenarios and clean up after my useeffects! So far it seems to work fine.

[Hyperkid123]

Ah right. Yeah if you are reading any values from the redux store it will force render on any value update.