Form components values - changes in V37.x

Hello,

There’s been a lot of great work in V0.37.x Thank you!

With the recent change to react-hook forms and the Redwood forms package, the behavior is a bit different for empty, non-required fields than before. This was something previously commented on and was changed in April of 2021.

The issue is most easily discussed for a <NumberField>, but it applies to some other types with value transformations as well. With the previous code:

• A <NumberField> that is set with validation as not required, and an empty field insde would return an undefined for the value.

With the current code:

• A <NumberField> that is set with validation as not required, and an empty field would will return a NaN for the value.

Our app has numerous non-required fields, and if the <NumberField> is blank, the value gets set to undefined and nothing bad happens on the API side when the object is sent over for a create or update mutation. With a NaN value being returned, this translates to a null over the graphql API. This has caused some bugs for us, but not difficult to fix.

I believe there are arguments for both sides to send back a null vs an undefined in this case.

The new Redwood forms code is definitely more straightforward now, so I see the overall value in the latest code organization. Do we want to: A. Return to undefined as per our discussion and decision from April, and update the code to reflect, or B. Leave the functionality as is currently the case and update the documentation to reflect the new return value?

Please review the original issue and PR for full context.

References: #3376 appears to be the recent change where this took effect. #2162 is the original issue #2167 is the PR where the change was made to undefined values

@jtoar and @Tobbe, can we get your feedback on this? Thanks!

[cjreimer]

@Tobbe I can work on this! Hopefully this upcoming weekend. I’ll watch for progress and hopefully a merge on your existing PR, and then review what’s left. Does that make sense? Feel free to message me if more detailed coordination would be useful.

[cjreimer]

No problem, @Tobbe. It is not a high priority for us as we have already resolved it. Just a matter of cleaning up this issue in Redwood as the docs don’t match the code for this.

I expect it should be pretty stable for minor r-h-f updates. Right now, our wrapper for r-h-f is one file (~800 lines with comments). It will add some complexity to put this in … I haven’t looked at it in detail yet.

If this can be done with minimal effort, I agree it’s worth it. However, I wouldn’t want to put in hundreds of lines of code, which then need to be maintained, to make it happen if that’s what’s required. So perhaps when I have time at some point, I’ll take a look and see what it would take.