Replies: 2 comments
-
In building out a rough version on the wip/v2-test branch I don't like how this would work. It would involve the user doing something like class MyStyles extends Stylesheet {
constructor(name: string = 'my-styles') {
super(name);
const token = new Token(this, 'primary', 'blue');
const darkQuery = new MediaQuery(this, 'prefers-color-scheme: dark');
token.addVariant(darkQuery, 'orange');
}
}
const token = new MyStyles();
await token.build(); I dislike having to extend the class in order to add the items as necessary. In this, however, I did end up abstracting out the logic for the "Selector" logic, which I think I'll pull into V1. |
Beta Was this translation helpful? Give feedback.
-
Alright, so I've decided to not go the way of the AWS CDK; Instead we are using the way originally introduced with some variations. There are now general The capability to add in actual CSS declarations are there now with the inclusion of the Selector, but I don't see a use for them at this time so I likely won't be adding them in until there's a need. We also removed the TokenType enum; while I may only see the need for two types of tokens, odds are someone else will need something much more generic. It is now a string that defaults to I'm also going to need to add in configuration type to be exported out for people to use, along with the CLI for people to use in place of running the code manually. |
Beta Was this translation helpful? Give feedback.
-
There are two ways I can see to go forward with the project.
The first is the current path, with a bit of decoupling between the pieces but for them all to be made into a stylesheet at the user's own work.
The other way i can see is something akin to the pattern that the AWS CDK uses. Let me work up a feasible example to compare/contrast how the code is going and determine which way feels the best.
Beta Was this translation helpful? Give feedback.
All reactions