Fix bug where matching anyOf branch is not selected correctly

[LucianBuzzo]

This change improves the logic that selects a matching anyOf branch
based on form data. Previously the behaviour was to just check if the
form data was valid against an anyOf branch, however due to the
permissive nature of JSON schema this has unexpected behaviour. For
example, given the following schema:

{
  "type": "object",
  "anyOf": [
    {
      "properties": {
        "foo": {
          "type": "string"
        }
      }
    },
    {
      "properties": {
        "bar": {
          "type": "string"
        }
      }
    }
  ]
}

The form data { bar: 'baz' } will actually match the first branch. To
mitigate this, when doing the matching, the branch schema is augmented
to require at least one of the keys in the branch. For example the
schema above would become:

{
  "type": "object",
  "anyOf": [
    {
      "properties": {
        "foo": {
          "type": "string"
        }
      },
      "anyOf": [
        { "required": [ "foo" ] }
      ]
    },
    {
      "properties": {
        "bar": {
          "type": "string"
        }
      },
      "anyOf": [
        { "required": [ "bar" ] }
      ]
    }
  ]
}

Signed-off-by: Lucian [email protected]

Checklist

• I'm updating documentation
  • I've checked the rendering of the Markdown text I've added
  • If I'm adding a new section, I've updated the Table of Content
• I'm adding or updating code
  • I've added and/or updated tests
  • I've updated docs if needed
  • I've run npm run cs-format on my branch to conform my code to prettier coding style
• I'm adding a new feature
  • I've updated the playground with an example use of the feature

[LucianBuzzo]

@glasserc If you have time a review would be great! This fixes an annoying bug with my original anyOf PR.

[glasserc]

Do we need a test this complicated? Can't we just render it with {idCode: "something"} and see if the select shows the right value?

[LucianBuzzo]

This test specifically checks to see that the selected value remains as expected after the user inputs a value, which is subtly different to checking that the correct value is selected when data is already present. The other validations in the test are sanity checks to make sue the form is in the state we expect before inputting a value.
It might seem a little verbose, but the verbosity will help ensure that there are no future regressions or that the test reports false positives.

[LucianBuzzo]

@glasserc Thanks for the detailed review 👍 . I've addressed your comments and the PR should be good to go now.

[epicfaace]

@LucianBuzzo I'm wondering, why did you wrap the required attribute in another anyOf -- couldn't you have created an augmented schema like this?:

{
  "type": "object",
  "anyOf": [
    {
      "properties": {
        "foo": {
          "type": "string"
        }
      },
      "required": [ "foo" ]
    },
    {
      "properties": {
        "bar": {
          "type": "string"
        }
      },
      "required": [ "bar" ]
    }
  ]
}

[LucianBuzzo]

@epicfaace Wrapping the required in anyOf is a trick to allow you to require at least one of a list of keys, which is what you need to do if the subschema is a more complex object, for example:

{
  "type": "object",
  "anyOf": [
    {
      "properties": {
        "foo": {
          "type": "string"
        },
        "bar": {
          "type": "string"
        }
      },
      "anyOf": [
        { "required": [ "foo" ] },
        { "required": [ "bar" ] }
      ]
    },
    {
      "properties": {
        "buzz": {
          "type": "string"
        }
      },
      "anyOf": [
        { "required": [ "buzz" ] }
      ]
    }
  ]
}

If you just use a plain required statement, then the first object wouldn't match if you start typing into the foo field, but the bar field is still empty.