focus/change/blur is not a function

[FC-jan]

Are you submitting a bug report or a feature request?

bug report

What is the current behavior?

We get live bugsnag reports about focus/change/blur not being a function since our latest release:

TypeError P.blur is not a function
TypeError P.change is not a function
TypeError P.focus is not a function

Sadly, I don't know how our prod users achieve the error.
Looking into the prod source, the same places' breakpoints trigger on blur/change/focusing a react-final-form input.

Main change suspected that started to cause this:

-    "final-form": "^4.20.6",
-    "final-form-arrays": "^3.0.2",
+    "final-form": "^4.20.9",
+    "final-form-arrays": "^3.1.0",

Going through the changeset from 4.20.7 to 4.20.8, 33e551f caught my eye. It changed the blur/change/focus function handling and may not work in all cases.

What is the expected behavior?

Focus/Change/Blur should be a function if existing, and only be called if it's a function.

Sandbox Link

Sadly none.

What's your environment?

Browser: Current Chrome.

Our project is huge, but related to this project should be these dependencies:

"final-form": "^4.20.9",
"final-form-arrays": "^3.1.0",
"final-form-calculate": "^1.3.2",
"react": "^17.0.2",
"react-final-form": "^6.5.9",
"react-final-form-arrays": "^3.1.4",

Other information

Sorry for not providing more info outright, I'll try to provide what I can when asked.

[FC-jan]

Just to confirm, the error vanished after rolling back final-form only, to 4.20.7.
This would further support the theory that the cause probably is 33e551f.

Would still like to get to the bottom of this, as staying with 4.20.7 forever is not our preferred way to go :/

[gertdreyer]

33e551f solved a big bug in arrays so I would like to build on those changes instead of rolling back.

Is it possible to provide a CodeSandbox of some sort of mock-up that we can debug more effectively?

I think we may have some success by just conditionally executing those methods.

[FC-jan]

Excuse the delay - I wanted to provide a CodeSandbox (failed try: https://codesandbox.io/s/nifty-morning-fwf5sb?file=/src/App.tsx) to not just prevent the error but allow for the best behavior possible. Also asked fellow devs with code insight for creative ideas without success. I have no idea how our end users achieve this :/

Absolutely agree with keeping and improving the fix - we only had to roll back on our side.

I think I have to give up regarding the reproduction :/

Conditionally executing the functions should at least prevent the error. I'm just not sure what the behavior will then be.
Also, I'm wondering where that condition should be placed, as the calls might be anywhere from my understanding. I think it should be wrapped close to the field, so the outside can blindly call blur/change/focus without regard.

If I can assist in that regard, please let me know. Am willing to provide a PR as well, just don't know the project internals too well so far.

[gertdreyer]

I attempted to trigger the error with your Sandbox. Here is a forked version: https://codesandbox.io/s/nervous-grass-dsy7k0?file=/src/App.tsx

I thought it may happen when you call focus or change on a field that is not currently rendered, but that does not seem to be the case...

Other possible causes that I can think of:

• The source error is located in either final-form-arrays, react-final-form-arrays, or calculate.
• New behaviour of arrays - empty arrays return to undefined to match the normal fields, the previous behaviour can be achieved with an identity function passed to the parse callback. But that seems to be fine from my tests....

[FC-jan]

minor update for anyone wondering:
Gert and me had a quick hangout to demo my use case, it's difficult to transfer to a sandbox. To make the most of it, I prepared a re-release with the versions affected - and didn't get the error anymore. 🤯

One change since then was that we replaced a very busy section of our form that indeed was array-based. Our replacement is more distant from final-form and just interacts via form.changes. So far, we can only suppose that it was the culprit and don't know exactly how we worked around it.

Will still try to reproduce/provoke the issue with some final-form-arrays-insights Gert provided me with - but this might as well be it for this issue :/