placeholders / runtime generation

[M1cha]

It'd be great if we could add support for place holders similar to what leptos' view! macro does. To get started, this would probably the easiest to do as an alternative to style_str! so you don't have to care about how to insert it into the DOM yet (which might be framework specific).

I don't think we should actually parse the CSS at runtime (like stylist does). Instead, we could follow an approach similar to format_args! (which is what format! uses internally) where you basically emit a structure that contained the parsed state so you can simply render the style while considering the placeholders.

One might ask if such a feature is in scope for this crate. I'd argue yes since the actual CSS parser can still be the same - all we have to do is to change the output of the macro.

My current usecase: I wrote a grid component that uses a CSS grid layout internally. This prevents having to execute javascript code on every resize. It also utilizes CSS media queries so you don't even have to run any javascript code to make the layout change after resizing the viewport. The hope is that this improves performance and reduces code complexity since I'm using functionality that's already present in the browser. But that also means that I have to generate a lot of scoped grid-column: a / b; grid-row: c / d; rules for every cell.

[abishekatp]

Hi, Please correct me if I am wrong. Are you saying that you want to use rust variables in places of css property values. Like below

style_str!{
  .one {
    grid-column: {a / b};
    grid-row: {c};
  }
}

Here instead of using the 1/3 directly using you want to use some variables {a/b}.

I think(may be wrong) in CSSStyleDeclar struct we can modify the struct with keys as strings and values as Rust expressions. Also we have to return the CSSStyleSheet struct as the return value of the style_str macro. Then call something like to_string at runtime to get the final style string. I think this can be done to style_str macro because it is neither storing css value in separate css file nor reading css from external css file, which is case for other three macros. If this is what you were saying, I was also thinking about it. This might be the right time to try that out.

[M1cha]

Yes that's exactly what I mean :) We could return CSSStyleSheet from style_str but should make sure to only do that if there are any expressions so we don't waste runtime-resources in places where that's not needed. I don't know if it's considered acceptable to have macros return different types depending on the arguments though.

[abishekatp]

There are some possible solutions for this

• One way could be returning a Enum type based on weather expression is there are not. But In this way user might have to always handle the different cases of enum.
• The other way could be exposing separate macro for this. But I am thinking like "are we creating too many public api's for similar use cases?" Hope we will get some conclusion here :)

[M1cha]

I think I'd prefer simply making the return type depend on the arguments since that's would it easier to use. Also, the user doesn't really have to know what the actual type is if we provide an interface like ToString.

[abishekatp]

Yeah that would be better idea. I will work on it.

[abishekatp]

Hello folks, First of all thank you for opening this issue @M1cha. I have been thinking about this problem for some time. I think only way to achieve this placeholder is by at least shifting some part of the logic to the runtime(Our goal is to be fully compile time). I think most of the important stuffs which needs placeholder feature can be achieved by just conditionally switching the class names or directly passingt it to the html element style attribute. So as of now and we will focus on the some other major things like this issue.

@M1cha I want to ask you whether can we close this issue as of now and if there is some necessity in future we can create new issue for this?

[M1cha]

@abishekatp Unfortunetely style/class don't work

• class: doesn't allow taking input from local variables like the grid numbers of the sample I provided
• style: doesn't support media queries

I fully agree that it's more important to focus on issues like the one you mentioned which might need refactoring the core architecture.

shifting some part of the logic to the runtime(Our goal is to be fully compile time)

I get that, and it's your call to make if you want to support it or not. When I wrote this issue I only knew about stylist and stylers. And stylist seemed both inconvenient(since you need to pass a string, you have to run the code to see if it's correct) and probably inperformant. But the leptos documentation just made me aware of "styled" which seems to do exactly what I want. I haven't tried it yet but based on their samples it looks pretty good.

The only complain I have is that y'all need better naming, I never know if what I'm currently using is called stylist, stylers or styled :sweat_smile:

TL;DR: Yes, it's okay if you close this. Thanks a lot for your awesome work and fast support :+1:

[abishekatp]

Thank you