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

Add named schemas for missing built-in types #13

Closed
tingerrr opened this issue May 30, 2024 · 2 comments · Fixed by #18
Closed

Add named schemas for missing built-in types #13

tingerrr opened this issue May 30, 2024 · 2 comments · Fixed by #18
Labels
enhancement New feature or request schema Issue or PR relating to valkyrie schema
Milestone

Comments

@tingerrr
Copy link
Member

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.

@tingerrr tingerrr added enhancement New feature or request schema Issue or PR relating to valkyrie schema labels May 30, 2024
@jamesrswift jamesrswift added this to the 0.2.1 milestone May 30, 2024
@jamesrswift jamesrswift linked a pull request Jun 2, 2024 that will close this issue
20 tasks
@jamesrswift
Copy link
Member

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.

@tingerrr
Copy link
Member Author

tingerrr commented Jun 2, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request schema Issue or PR relating to valkyrie schema
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants