fix: distinguish between 0 and undefined in getMatchingOption

[hermansje]

Reasons for making this change

Updating the data for a form with oneOf or anyOf didn't correctly update the form UI if the new data complies with the first option.

The reason for this was that getMatchingOption, the function that determines what option the data adheres to didn't differentiate between 0 (the first option should be selected) and undefined (the data doesn't match any of the options), for which the most common fallback is 0 (selecting the first option). MultiSchemaField needs to do something else based on this difference, so getMatchingOption now returns undefined when data doesn't match any of the options and all places where the function is called handle this new return value.

Minimal steps to reproduce:

1. View the One Of example in the playground
2. Fill in some text in the form
3. Copy the formData
4. Make the form select the second option, either using the select input or by changing the formData to comply with the second option
5. Reset the formData using the copied data
6. Observe the second option is still selected and its form is still shown

Checklist

• [ ] I'm updating documentation
  • [ ] I've checked the rendering of the Markdown text I've added
• [x] I'm adding or updating code
  • [x] I've added and/or updated tests
  • [ ] I've updated docs if needed
• [ ] I'm adding a new feature
  • [ ] I've updated the playground with an example use of the feature

[hermansje]

@epicfaace The reason to give getMatchingOption a different return value for 'data matches the first option' and 'data matches none of the options' is that they need different behaviour. Without it, the form and the data could get out of sync, which you can see by following the reproduction steps above or verifying that the updated tests fail if you revert the changes to the logic.

This were the two cases where getMatchingOption returned 0:

1. When data matches the first option in oneOf or anyOf expected behaviour: the form updates to show the first option
2. When data matches none of the options expected behaviour: a fallback is chosen

When getMatchingOption returned 0, MultiSchemaField treated it as the second case, and the fallback it implements is to not update the form because keeping the currently selected option is as correct as showing a different option. But when getMatchingOption returned 0 because of the first case, which should update the form, it didn't since it was impossible for MultiSchemaField to distinguish this case 1 from case 2.

The solution is to either distinguish between the two cases in the return value of getMatchingOption or give case 1 and 2 the same behaviour (always render the first option if the data matches none of the options), but this is less flexible and would change how the fallback in MultiSchemaField works.

[hermansje]

@epicfaace is there something more I can do to get this PR merged?

[hermansje]

@epicfaace I rebased the PR and the CI still passes. The test updates in this PR add cases that fail before the fix and pass after.

[epicfaace]

@hermansje sorry for the delay. I didn't really understand your explanation, maybe we can have a call here (https://calendly.com/aramaswamis/meeting?month=2020-07) to discuss further?

[heath-freenome]

Closing as this method is now deprecated and getClosestMatchingOption() has been implemented