Are you submitting a bug report or a feature request?
Bug Report
What is the current behavior?
It appears that get and setIn are now quite slow, probably thanks to the full JS path syntax support in my merged PR. (See screenshot) I didn't think about that risk...
Given that I copied the get/set code from lodash, I assume it's pretty optimized already and supporting full JS pathstrings with high performance may be intractable. The lodash code even caches parsed paths, but this doesn't help the first time a field is seen; I'm using RFF fields in an infinite scrolling list, and it's always slow to add new rows because it takes time to parse the new pathstrings.
I think the only longterm solution would be to accept an array like ['Channels', 'foo.bar', 'name'] in place of pathstrings like 'Channels["foo.bar"].name'.
What is the expected behavior?
We have a way to change a field that's extremely fast
Sandbox Link
What's your environment?
final-form: 4.20.4
react-final-form: 6.5.7
Other information
Are you submitting a bug report or a feature request?
Bug Report
What is the current behavior?
It appears that
getandsetInare now quite slow, probably thanks to the full JS path syntax support in my merged PR. (See screenshot) I didn't think about that risk...Given that I copied the
get/setcode from lodash, I assume it's pretty optimized already and supporting full JS pathstrings with high performance may be intractable. The lodash code even caches parsed paths, but this doesn't help the first time a field is seen; I'm using RFF fields in an infinite scrolling list, and it's always slow to add new rows because it takes time to parse the new pathstrings.I think the only longterm solution would be to accept an array like
['Channels', 'foo.bar', 'name']in place of pathstrings like'Channels["foo.bar"].name'.What is the expected behavior?
We have a way to change a field that's extremely fast
Sandbox Link
What's your environment?
final-form:4.20.4react-final-form:6.5.7Other information