Merge forks, medium term goals and the future of the library

[WorldSEnder]

While maintaining my own fork of css-in-rust I noticed that you are also kinda active catching up to yew etc. I believe it could be beneficial to combine our efforts so to say.

My plans with the library were the following:

• Instead of the parsing infrastructure, maintain a proc_macro crate and use type-structured input in the main crate. This should reduce the output size of the emitted wasm.
• Interface with the upcoming hook interface of yew.

Let me know what you think about that and if I should spend the effort to get a PR going.

[futursolo]

Thank you for reaching out with the offer and I agree that it would be better to join our effort.

There're three reasons why I forked the library:

1. Yew 0.18 Support
2. Easier Theming
3. Fix bugs and improve codebase

I was also thinking about a procedural macro but haven't got time to address this as I am still in the process of cleaning up and adding tests to the existing APIs.

A procedural macro will not only result in a small codebase but also:

• Has no runtime cost on parsing.
• Reports errors at compile time.
• Enables a potential format!-style syntax for theming.

However, I kind of prefer to keep the existing runtime-parsing API as there might be cases where it's easier to generate style at runtime based on different conditions.
Maybe we can have the runtime APIs behind a feature?

As for the hooks, I think they probably need to be in a different crate until function component becomes stable.

Also, do you think it's better to create an organization and transfer the repository there?

[WorldSEnder]

However, I kind of prefer to keep the existing runtime-parsing API as there might be cases where it's easier to generate style at runtime based on different conditions.
Maybe we can have the runtime APIs behind a feature?

With a macro-style crate, I'd think the easiest dependency structure would be

stylist (depends on, and reexports part of -core, based on features)
├── stylist-core
└── stylist-macro
    └── stylist-core (*)

Anyone interested in the runtime API would then import either stylist-core directly or toggle a feature in stylist.

As for the hooks, I think they probably need to be in a different crate until function component becomes stable.

True that, I'm not 100% sure if one can have a feature that turns on some kind of yew@next integration and how that interacts with crates.io (no git dependencies allowed).

Also, do you think it's better to create an organization and transfer the repository there?

At some point yeah, in the mean time keeping it here is fine too, I'm fine with it just being a PR.

[futursolo]

What would be your preferred syntax for the proc-macro?

Since I mentioned about having both runtime API and proc-macros, it would be nice to have both API to use the same parser so less effort to maintain in the long run.

I guess it might be better for the proc-macro to take a string literal as style input?

I also fine with other syntaxes as well if it looks nicer than string literals.

[futursolo]

Interface with the upcoming hook interface of yew.

Let's manage this in #23 and close this issue as other goals are fulfilled.