Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

document use of oneOf prop within schema #4758

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

kylebakerio
Copy link
Contributor

@kylebakerio kylebakerio commented Dec 29, 2020

Description:

Changes proposed:

@@ -178,6 +178,16 @@ schema: {type: 'string'} // default: ''
schema: {type: 'vec3'} // default: {x: 0, y: 0, z: 0}
```

#### Specifying Possible Values

You can also provide an array of acceptable values to use:
Copy link
Member

@dmarcos dmarcos Dec 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be misleading? The value range is not checked at run time. It's only a hint for the inspector to show the combo box widget. We should probably add a #### Inspector section explaining: the property type is used by the inspector to show the appropriate widget. max and min can be used to constrain the range of available values and oneOf to display a list of options.

@kylebakerio
Copy link
Contributor Author

kylebakerio commented Dec 30, 2020

I see. I definitely think that would be misleading, then. I can either update this text block with the correct description, or we can format it under a different section (I think that also makes sense, I've always wanted to find some full inspector documentation)... But are there objections to just adding this functionality as an option (runtime comparison of this kind)?

@dmarcos
Copy link
Member

dmarcos commented Jan 5, 2021

Not sure if runtime boundary check is very useful. We could print warnings in console but comes with a performance penalty due to the additional logic and increases complexity in code that it's already complex. My preference would be to wait and see more demand for such a feature.

Regarding docs. Maybe adding a note in the inspector / components section explaining how property types are used to display the appropriate widget. Does it sound good? Thanks so much for the improvement suggestions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants