Multiple type definitions behavior questions

[SachaG]

I would love some more details about the expected validation behavior when defining multiple types for a field (as outlined in the Multiple Definitions For One Key section).

If I define that a field can be of type Foo or type Bar, is the field validated against both types successively and passes if at least one of the type's validation passes?

Is there a way to define a function to manually indicate which type should be used? My use case is making a survey builder. Depending on the survey being filled out, the data field of my documents can be different, but I know what to expect so ideally I would be able to specify which of the multiple possible survey schemas to validate the document against. Does that make sense?

[github-actions]

Thank you for submitting an issue!

If this is a bug report, please be sure to include, at minimum, example code showing a small schema and any necessary calls with all their arguments, which will reproduce the issue. Even better, you can link to a saved online code editor example, where anyone can immediately run the code and see the issue.

If you are requesting a feature, include a code example of how you imagine it working if it were implemented.

If you need to edit your issue description, click the [...] and choose Edit.

Be patient. This is a free and freely licensed package that I maintain in my spare time. You may get a response in a day, but it could also take a month. If you benefit from this package and would like to see more of my time devoted to it, you can help by sponsoring.

[aldeed]

@SachaG Yes, I believe what you said is correct. As long as one type validation results in no errors, it's assumed to be valid. For your needs, is it possible to build a factory function that dynamically builds the schema and returns it?

Or if using collection2, then the multiple schemas approach is often used for that case: https://github.com/Meteor-Community-Packages/meteor-collection2#attaching-multiple-schemas-to-the-same-collection

Either approach essentially involves having more than one schema. Some parts of field definitions can be a function, but not type, and there has been no attempt to do that AFAIK. It might be possible, but I think it would be yet another new feature similar to but separate from SimpleSchema.oneOf.

[znewsham]

I believe the implementation of oneOf may be buggy - I'm currently using this and it is attempting to validate all keys of all sub objects. My use case is almost identical to @SachaG, however I don't think that is relevant - it seems that any field defined as SimpleSchema.oneOf(Schema1, Schem2) will have this problem

[znewsham]

I now see that perhaps this has already been reported here: #112

[github-actions]

🎉 This issue has been resolved in version 3.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

If this makes you happy, please consider becoming a sponsor.

Your semantic-release bot 📦🚀