You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some types, such as gradient, stroke, or even simpler ones like label or selector do not yet have schemas.
Some others which are more complex deserve getting dedicated schemas like validation for queryable element functions, countable element functions etc. (what is internally tracked using traits on elements) should likely be included as choice schemas.
The text was updated successfully, but these errors were encountered:
Gradient, Stroke, and Version are now implemented by #18. I'm having a tough time thinking of potential use cases or applications of label and selector (mostly because I've never really needed to use them myself so they are still a bit alien to me), so I'm having a tough time thinking about what exactly needs to be implemented for these, for the job to have been done properly.
Regarding labels and selectors, they are relevant to, for example, hydra. While they are only a subset of the type queryable, they are part of building such a schema and definitely important for packages which implement introspection heavy packages.
I think for the base types it's fine if they simply check the type as the other regular ones do, see my review comment on the PR which lists the built-in types. I think we should provide all of those by default, even if they are simple.
Some types, such as
gradient
, stroke, or even simpler ones likelabel
orselector
do not yet have schemas.Some others which are more complex deserve getting dedicated schemas like validation for queryable element functions, countable element functions etc. (what is internally tracked using traits on elements) should likely be included as choice schemas.
The text was updated successfully, but these errors were encountered: