Internally reduce `oneOf`/`anyOf` blocks to only the currently selected subschemas to avoid undesireable extra validation errors

[TheOneTheOnlyJJ]

An idea that just came to me would be dynamic schema modifications done internally.

I could see something like having the subschema selector from the form trigger a function that literally cuts out all the subschemas from the oneOf/anyOf and passes that programatically reduced/normalized schema to the validator. This way, the validator does not "know" about any other subschemas but the one currently selected in the form through the selector field, and will only validate against it and no other. To take things one step further, the entire oneOf/anyOf field could probably be replaced with the currently selected subschema.

This would add the overhead of recompiling validators every time the selector is changed, unless all possible validators could be precompiled on form creation and used depending on the current subschema selection from the form. For complex schemas, this is probably unfeasible as it would take a lot of time or even memory.

This would also not work with precompiled schemas, which is a bummer.

I don't have any other ideas on how to get around this. It is a bummer that AJV itself seems to be unmaintained, as that would probably be the better place to address this. I am genuinely concerned about its future as a library.

Hmmmm, Food for thought. Could you write up a new feature issue with your idea? It's possible we could figure out something that could also work for precompiled schemas

Originally posted by @heath-freenome in #4884 (comment)

As mentioned in the above comment, a possible way to avoid validation errors of fields coming from anyOf/oneOf subschemas that are not the currently selected subschema in the form would be to have the Form component dynamically remove the entire anyOf/oneOf blocks and replace them with only the specific subschemas that are currently selected in the form, based on the anyOf/oneOf subschema selector fields.
This programatically reduced and more specific subschema would then be passed to the validator, avoiding the redundant validation of subschemas that are not the current target subschema and the redundant errors that come with it.

Consideration should be taken on when and where the schema validator compilation should happen, as it could be resource-heavy for large schemas and many changes/interactions with the subschema selectors in the form.
Maybe a specific schema for every possible combination could be compiled once on Form component creation and cached in a map to be used dynamically depending on the user inputs, but a proper benchmark should be done to determine the best path forward.

Precompiled schemas are also something to think about, and are currently an open-ended question.

[x0k]

Maybe this kind of transformation would work? (pseudocode):

const { oneOf, anyOf, ...rest } = originalSchema;
const alt = oneOf ?? anyOf; 
const schema = mergeSchemas(rest, {
  properties: {
    virtual_property: {
      enum: alt.map(toOption)
    }
  },
  dependencies: {
    virtual_property: {
      oneOf: [
        ...alt.map((s, i) => mergeSchemas(s, {
          properties: {
            virtual_property: {
              const: toOption(s, i)
            }
          }
        }))
      ]
    }
  },
  required: ['virtual_property']
})

Then use the omitExtraData algorithm with the original schema to remove the virtual_property.

Edit: Playground