Replies: 2 comments 2 replies
-
|
This is an area I'm interested in improving. Not a fan of loosening the types. I wonder if providing an explicit type for the |
Beta Was this translation helpful? Give feedback.
-
|
if its only loosening the types near the SystemStyleObject then it should be fine as long as we keep the typings for the possible key/value variant pairs it might be worth it to check if your change doesnt impact negatively the typechecking speed; you can do so either with https://www.typescriptlang.org/tsconfig/#diagnostics (look for Instantiations/Check time in the output, lower is better) / https://github.com/microsoft/typescript-analyze-trace |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Description
The
cva,svarecipe functions currently infer both variants and the css of each variant. I would like them to only infer variant names and their values because the inferred css can be quite large.Problem Statement/Justification
I propose this because of the following issues I've noticed when using cva/sva:
The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.ts(7056)when trying to reuse styles across multiple variants in a recipe (example).variantsproperty. This makes it hard to debug large recipes (example).Proposed Solution or API
I would like to suggest looser inference in the inferred variant type in cva and sva as shown in the following files:
I'm not sure if these types are performant, but I hope this creates a starting point for limiting inference there.
Alternatives
For the max serialisation length error, I have tried using
satisfiesinstead of directly setting the type of the shared styles toSystemStyleObject, but that seems a bit unintuitive.i.e:
Additional Information
No response
Beta Was this translation helpful? Give feedback.
All reactions