Styling Brainstorming

[jkelleyrtp]

I'd like to add a styling system to yew - not having a built-in way of styling components seems a bit unfinished to me. If we want to build better, bigger, and faster web apps, then we need a way of managing styles that doesn't clobber a global namespace and makes sense when looking at the components.

I'd like to see a Stylable trait where we can pull in an existing stylesheet (using css-parser for the servo project), modify it (override the defaults), and then set that as the element style.

We could also have a special style property for each element where we can inject style into even the subdivs of elements.

I personally favor parsing an external stylesheet and doing inline modification because of autocompletes working with .css files, but there is also room for a css! macro and reserve a keyword for the element that the style is being applied to, to access subdivs in that element.

Curious what the thoughts of the community is before I try pull my changes into the project.

[ThomasdenH]

I think the system for styling would be best as a separate system, where individual properties are ideally strictly typed. Then the library could be integrated here.

[jstarry]

I agree with @ThomasdenH and think this could start out as a separate crate but could eventually get added to yew later as it matures, perhaps in the form of "styled components".

@jkelleyrtp are you thinking of taking approach like https://cssinjs.org/? I would love having a way to use declarative styles like this. Then the integration with yew is as simple as setting the class name

[jkelleyrtp]

@jstarry I was definitely feeling inline CSS in the same way that JSS works - I like having the state of the component directly tied to its appearance. I'm going to approach this in the same way that styled-components work so we can just drop existing stylesheets into components but also be able to modify them on component updates.

[matiu2]

Personally I just use bootstrap. Then apply the class attributes as needed: https://hackerthemes.com/bootstrap-cheatsheet/

I don't use the JS part of it; just the stylesheets.

I can imagine possibly a high level API that just applies those, but I think I would prefer to just apply them myself.

The question is where does the scope of yew end ? perhaps what's needed is a separate yew-styling plugin/library ?

[hgzimmerman]

@jkelleyrtp Have you made any progress towards this?
I have a loosely defined proposal on how to implement this typed up and would love to give it a shot in building it, but if you have something in the works, I would rather hold off and wait on that.

[hgzimmerman]

Nevermind, I've got a prototype in the works here in case anyone wants to check it out:
https://github.com/hgzimmerman/yew_css

[MuhannadAlrusayni]

Here is my thoughts on building styling system.

I think there are two different places that we need to handle style:

1. a default style for every component.
2. a unique style for every component instate.

A default style for every component

Every component can have it's own default style, let's say a Button component have this default style:

color: black;
background: white;
border: 1px solid black;
border-radius: 4px;

At this point we need to defined the behavior of the styling system, thus we need to answer these questions:

• How the styling system will get these default styles? and from where?
• How the styling system will apply these default styles to the components ?

A unique style for every component instate

Some times we change style for component instate, by adding, removing .. etc styles to the component instate, thus we need to defined a how the styling system would allow us to do that.

possible answer for the 1st question

How the styling system will get these default styles? and from where?
By using trait Theme that would return Style struct that contains CssName and CssValue pairs, for the component. Every theme struct would implement this trait.

Theme that uses classes

This trait uses the class to construct Style for it. this trait is simple to implement but doesn't have full access to the component state. it also can have styles even if we have no components for them, it is easy to reuse existing css libraries with this trait.

    pub trait Theme {
        fn style(&self, class: impl Into<Cow<'static, str>>) -> Option<Style>;
    }

    // example
    pub struct DefaultTheme;

    impl Theme for DefaultTheme {
        fn style(&self, class: impl Into<Cow<'static, str>>) -> Option<Style> {
            match class.into().as_ref() {
                "button" => unimplemented!(),
                "flexbox" => unimplemented!(),
            }
        }
    }

Theme uses components state

This trait uses the component state to build Style for it, it have full access to the component state, but it's not simple to implement as well as it's only support components that are present in Component enum.

    pub trait Theme<Comps> {
        fn style(&self, class: impl Into<Comps>) -> Option<Style>;
    }

    // example
    pub struct DefaultTheme;

    impl<'a> Theme<Components<'a>> for DefaultTheme {
        fn style(&self, comp: impl Into<Components<'a>>) -> Option<Style> {
            match comp.into() {
                Components::Button(btn) => unimplemented!(),
                Components::Flexbox(flexbox) => unimplemented!(),
            }
        }
    }

    pub enum Components<'a> {
        Button(&'a Button),
        Flexbox(&'a Flexbox),
    }

This my try, for sure there are a lot of things that need to be changed for these ideas to fit in Yew. I didn't answer the other questions, since I don't have clear answer for them.

[richard-uk1]

I'm having a play with writing a css parser from rust tokens, and it seems to be going well. It's available at https://github.com/derekdreery/style. The idea is that you can do things like

<div style={{font-size: 10px; flex-direction: column}}></div>

from within a macro in rust code, making using css/styles feel really natural.

[jstarry]

Wow, awesome @derekdreery! Looks like the yew html macro could depend on your style macros under the hood. Is that what you had in mind?

[kellytk]

I agree with

individual properties are ideally strictly typed

from #533 (comment).

[richard-uk1]

Looks like the yew html macro could depend on your style macros under the hood. Is that what you had in mind?

Happy to help out however you want to use them.

There are a couple of small caveats:

• hex colors are not valid tokens in the rust lexer, so they have to be quoted (e.g. color: #"fff")
• same goes for lengths that start with e (this is because the lexer tries to interperet the number as a float with an exponent). (e.g. font-size: 1"em")

individual properties are ideally strictly typed

The lib I'm working on does typecheck your CSS, so only valid types of property values are allowed for a given property name.