lukejacksonn / lukejacksonn/oceanwind
Consider exposing supported syntax and its variants
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 264
- Forks
- 11
- PR merge metrics
- No merged PRs in 30d
Description
I use TypeScript to provide typing over Oceanwind in my current work. I provide a sx prop for components where you can provide Oceanwind classes within a string (could be an array of strings).
At the moment, the type for this is any and that makes sx a little dangerous to use. To improve DX, it would be better to allow only syntax that's supported by Oceanwind.
Would it be feasible to generate the syntax and its different permutations within a module so that it's possible to type systems to infer available options? I am currently using this kind of approach against the theme for type inference for more specific props than sx.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the sx prop typing and the existing theme type-inference approach described in the issue. Define the supported Oceanwind syntax and its variants, then verify that consumers can infer only those options while preserving the documented string or array usage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, typescript
- Domain
- developer-experience, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100