Roadmap

[Zn4rK]

I recently stumbled upon this project whilst looking into performance issues with vanilla-extract.

I like the simplicity, and the fact that it seems to be truly atomic css. I've done some tests with provided playgrounds, and it is working very nicely.

I was mainly wondering about the roadmap. What do you want to add or change before this can be considered for a production release? Do you need help with anything?

I was also wondering about #90. It does seem like you still can use a single file for styles.

Is that intentional? If it is, very nice! My biggest issue with vanilla-extract is the fact that I can't co-locate styles to the components, and that I need to have multiple files. Kaze-style seems to solve this pretty well.

Thank you for your work so far. This is looking very promising!

[taishinaritomi]

Hi @Zn4rK !

Thanks for create the Issue.

I was also wondering about #90. It does seem like you still can use a single file for styles.

Is that intentional? If it is, very nice! My biggest issue with vanilla-extract is the fact that I can't co-locate styles to the components, and that I need to have multiple files. Kaze-style seems to solve this pretty well.

In Kaze-style, we run the js file with nodejs and extract the css.
In that case, there is a possibility that the UI library may have things that cannot be executed by nodejs, such as window, and we could not guarantee that it could be executed.
Currently, single file styles is possible, but not guaranteed.

The goal is to have guaranteed single file styles.

I was mainly wondering about the roadmap. What do you want to add or change before this can be considered for a production release? Do you need help with anything?

We aim to extend @kaze-style/themes and stabilize CSS extraction before release.
Also, kaze-style needs help.
kaze-style is currently being developed by me, alone.
However, I am not very knowledgeable about bundler(webpack,vite), so I need help with CSS extraction around bundler.
Also, I am not good at English and need help with Document grammar.

Contributions welcome!!

[Zn4rK]

Hi @Zn4rK !

Thanks for create the Issue.

No worries! I'm super excited about kaze-style!

The goal is to have guaranteed single file styles.

Nice!

We aim to extend @kaze-style/themes and stabilize CSS extraction before release. Also, kaze-style needs help. kaze-style is currently being developed by me, alone. However, I am not very knowledgeable about bundler(webpack,vite), so I need help with CSS extraction around bundler. Also, I am not good at English and need help with Document grammar.

Contributions welcome!!

I'm familiarising myself with the code base right now, and I will try to do some beneficial work in the coming days.

I've been sketching on a createTheme that works a bit like a simplified version of vanilla-extract. More for a proof of concept and trying to understand what the flow looks like. I'll create a PR for that hopefully later this week.

As for the documentation, I can probably help with that as well. English isn't my native language, but I'm sure we can work together to create something good! Good enough for a native speaker to correct our grammar :)

I haven't been working too much with vite, but I'm very familiar with webpack, and can hopefully help out there. Once I'm feeling more into the code base I can take a look :)

[taishinaritomi]

I've been sketching on a createTheme that works a bit like a simplified version of vanilla-extract. More for a proof of concept and trying to understand what the flow looks like. I'll create a PR for that hopefully later this week.

About @kaze-style/themes
@kaze-style/themes is somewhat different from createTheme on the vanilla-extract in that it is a design token that supports the early stages of development.
It is more like css-props or tailwind.

The goal is to have guaranteed single file styles.

I have a new idea to support single file styles
I will share it in a few days.

[taishinaritomi]

I have a new idea to support single file styles
I will share it in a few days.

#120 (comment)

[Zn4rK]

About @kaze-style/themes @kaze-style/themes is somewhat different from createTheme on the vanilla-extract in that it is a design token that supports the early stages of development. It is more like css-props or tailwind.

I have an idea that would work with the new idea of single file styles, and also be versatile to fit both css-props and an optional "createTheme" without adding bloat to the core (another package maybe). I'm still thinking and working on it, but I'll share a proof of concept very soon.

[taishinaritomi]

I have an idea that would work with the new idea of single file styles, and also be versatile to fit both css-props and an optional "createTheme" without adding bloat to the core (another package maybe). I'm still thinking and working on it, but I'll share a proof of concept very soon.

I am very interested.
Does it make any changes to the compiler(swc,babel)?

[Zn4rK]

Yes, minor to preTransform, but some big changes to transform. It will make sense if I can get it to work. My proof of concept works with babel-plugin, and I'm adapting the swc-plugin right now. The only drawback would be that the instantiation of new ClassName would need to happen in __style (and maybe __globalStyle) instead, but it would allow other developers to extend the core logic of kaze without breaking any functionality - at least in theory.

// pseudo code, mainly meant for demonstration, actual implementation will be more thought through.
export const __style = <K extends string>(classes: Classes<K>[]) => classes.map((x) => new ClassName(x));

If that's not acceptable and it needs to happen during compile time, that could still be handled in the transform-plugin.
But for the proof of concept I'll work around it, just to show off my idea, and we can polish it from there.

[taishinaritomi]

I would like to know how developers can use it.

Also, I would like to minimize the processing in the browser, so I would like to make the __style function a Noop function and do the processing at build time.

[Zn4rK]

Yep - I agree. __style and __globalStyle should be noop. I will try to work on my idea later tonight - and hopefully show you the idea.