Showing a previously removed value results in undefined error
🐛 Bug Report
When working with Visibility, toggling between removing a value using useData().remove() when hiding and then showing the fields related to to removed value causes an error.
I notice that after removing a value, it's not actually removed, but is set to undefined.
In another case, which is not relevant any more, I used set() to get the value properly removed from the data, but I don't think that is a very elegant solution.
Could/should remove() remove the key as well as the value from the data?
Or are there better ways to handle removing values when hiding them to avoid them being part of submitted data?
TypeError
Cannot use 'in' operator to search for '1' in undefined
at Object.set (https://swf6zr.csb.app/node_modules/
dnb/eufemia/extensions/forms/utils/json-pointer/json-pointer.js:45:16
at eval (https://swf6zr.csb.app/node_modules/
dnb/eufemia/extensions/forms/DataContext/Provider/Provider.js:426:28
at eval (https://swf6zr.csb.app/node_modules/
dnb/eufemia/extensions/forms/hooks/useFieldProps.js:1011:95
at eval (https://swf6zr.csb.app/node_modules/
dnb/eufemia/extensions/forms/hooks/useFieldProps.js:1039:7
commitHookEffectListMount
https://swf6zr.csb.app/node_modules/react-dom/cjs/react-dom.development.js:23150:26
commitLayoutEffectOnFiber
https://swf6zr.csb.app/node_modules/react-dom/cjs/react-dom.development.js:23268:17
commitLayoutMountEffects_complete
https://swf6zr.csb.app/node_modules/react-dom/cjs/react-dom.development.js:24688:9
commitLayoutEffects_begin
https://swf6zr.csb.app/node_modules/react-dom/cjs/react-dom.development.js:24674:7
commitLayoutEffects
https://swf6zr.csb.app/node_modules/react-dom/cjs/react-dom.development.js:24612:3
commitRootImpl
https://swf6zr.csb.app/node_modules/react-dom/cjs/react-dom.development.js:26823:5
commitRoot
https://swf6zr.csb.app/node_modules/react-dom/cjs/react-dom.development.js:26682:5
performSyncWorkOnRoot
https://swf6zr.csb.app/node_modules/react-dom/cjs/react-dom.development.js:26117:3
flushSyncCallbacks
https://swf6zr.csb.app/node_modules/react-dom/cjs/react-dom.development.js:12042:22
eval
https://swf6zr.csb.app/node_modules/react-dom/cjs/react-dom.development.js:25651:13
https://github.com/user-attachments/assets/00062ac1-c675-4f1a-9804-fe8f10b34434
To Reproduce
Steps to reproduce the behavior:
https://codesandbox.io/p/sandbox/remove-data-on-hide-swf6zr
Expected behavior
I expect the Fields to initialize the same way they do when they are first rendered when I show them after having removed them via remove().
Eufemia Version
10.53.0
I don't think we can use defaultValue when calling remove('/PEP/persons') – but we should make it work to use use emptyValue.
Ah, so the problem is that the field in the array has a defaultValue.
I see that it doesn't crash when I remove the defaultValue on the boolean field.
It also applies the defaultValue defined on the Iterate.Array correctly when pressing "Ja" and I check a checkbox again after.
So this is a bit strange perhaps?
@tujoworker I checked this again now since there have been a good deal of releases since it was posted, and it doesn't crash anymore, but the default values don't work (no names are shown) and something weird happens when toggling
https://github.com/user-attachments/assets/33dfe367-7b6f-4616-8534-e708c6fef194
I did test the reprod today, using latest version (v10.77.8), and I can still experience what's reported. That something weird happens when toggling. It's like every other time I press/toggle "Ja", the persons array is set to the default value, and the other time, it's empty/undefined. A bit strange.
In regards no names are shown, I don't think it has ever worked to use a Value as a label for a Value or Field, like so:
<Field.Boolean
itemPath="/x"
label={
<Value.Composition>
<Value.String itemPath="/y" />
<Value.String itemPath="/z" />
</Value.Composition>
}
/>
@langz Thanks for checking it out.
The Value usage works in the original issue version; 10.53.0.
That's not really a big deal, but actually nice to be able to do to not have to use the hook for getting those values.
@langz Thanks for checking it out.
The Value usage works in the original issue version; 10.53.0.
That's not really a big deal, but actually nice to be able to do to not have to use the hook for getting those values.
Thanks for the feedback, we were actually a bit unsure if it did work in previous versions of Eufemia or not. I found one example in https://github.com/dnbexperience/eufemia/pull/5394, perhaps it exists any tests for this? I don't see why it should not work or be a feature that Eufemia could support.
@tujoworker
The latest release does indeed support this:
<Value.String
itemPath="/valuePath"
label={<Value.String itemPath="/labelPath" />}
/>
Now we also have tests for it.