Separate parsing and core css functionality #10
Conversation
|
@futursolo alright, can you have a look over it and tell me if the design is okay to you so far, if there is anything missing that you want to see, and what should be documented better? |
packages/stylist-core/src/style.rs
Outdated
| /// // Example Output: stylist-uSu9NZZu | ||
| /// println!("{}", style.get_class_name()); | ||
| /// let scopes = Default::default(); | ||
| /// let style = Style::create_from_sheet("my-component", scopes); |
There was a problem hiding this comment.
Do we need to expose AST based Stylesheet API to public and having examples referencing them in the docs?
I was thinking about #[doc(hidden)] AST and anything that directly interacting with AST.
I guess that purpose of this is to be used with proc-macro, I cannot imagine that anyone would want to construct the Style this way.
There was a problem hiding this comment.
The main purpose of these methods is to advertise that you can create a Style without having to unwrap a Result, if you don't want to go through the (fallible) parser. I will add a comment to the docs about that.
There was a problem hiding this comment.
I also should mention that the macro will probably return a Sheet, not a style directly, so then you'd use these methods.
|
I want to add some bits of documentation to |
As mentioned in #8 this introduces two crates (macro part not implemented), one for the representation of css (
stylist-core) and the other for parsing and theyield_stylein (stylistitself).