How to mutate a rule in a stylesheet.

[paulm17]

Hello. I'm still very new to Rust and although I can now traverse the StyleRule struct. I'm having great difficulty in mutating it using the visitor trait.

Here's my use case:

.menuSlider {
  outline: rem(2px) solid var(--raikou-primary-color-filled);
}

I'm wanting to swap out rem(2px) with the following:

.menuSlider {
  outline: calc(0.125rem * var(--raikou-scale)) solid var(--raikou-primary-color-filled);
}

I'll give a basic example with hardcoded values, just to bring about the problem I'm having...

Note: I do have a function to retrieve the 2px from the rem function and then make the calculation. But I am omitting this in favour of brevity.

fn visit_rule(&mut self, rule: &mut CssRule) -> Result<(), Self::Error> {
  if let CssRule::Style(style_rule) = rule {
    let css = format!(
      "{}: {};",
      "outline",
      "calc(0.125rem * var(--raikou-scale)) solid var(--raikou-primary-color-filled)"
    );

    let new_declaration = DeclarationBlock::parse_string(
      &css,
      ParserOptions::default()
    ).unwrap();

    style_rule.declarations = new_declaration;
  }
  
  Ok(())
}

The issue is &css is not being dropped in the parse_string method of the trait DeclarationBlock.

`css` does not live long enough
borrowed value does not live long enough

At the end of the function bracket, if I hover over:

`css` dropped here while still borrowed

What's the solution? When I go through the source many functions have ticks or (long lives?). I am unsure how to resolve this issue. Or perhaps I am not using the library as intended?

Any advice would be most welcome!

Thanks!

[devongovett]

The problem is because you create css inside that if statement, and it gets dropped at the end. DeclarationBlock::parse_string borrows the string, it does not move/copy it. That means it depends on you keeping the string alive somewhere so that the parsed declaration remains valid. We borrow by default for performance reasons. That way there's no need to make copies of the string for portions we need to keep (e.g. variable names), we can simply reference a slice of the original string.

One way to solve this is with the into_owned feature. First, you need to enable it in your Cargo.toml.

lightningcss = { version = "...", features = ["into_owned"] }

Then, you can call into_owned on the parsed declaration block:

style_rule.declarations = new_declaration.into_owned();

This will walk through the parsed AST and clone any string references so they live longer than the original parsed string.

That said, I think it might be more performant and less error prone to operate directly on the AST rather than doing string manipulation and re-parsing. Something like this might work:

fn visit_token(&mut self, token: &mut TokenOrValue<'i>) -> Result<(), Self::Error> {
  match token {
    TokenOrValue::Function(f) if f.name.0 == "rem" => {
      if let Some(TokenOrValue::Length(LengthValue::Px(l))) = f.arguments.0.get(0) {
        *token = TokenOrValue::Function(Function {
          name: "calc".into(),
          arguments: TokenList(vec![
            TokenOrValue::Length(LengthValue::Rem(l / 16.0)),
            TokenOrValue::Token(Token::Delim('*')),
            TokenOrValue::Var(Variable {
              name: DashedIdentReference {
                ident: "--raikou-scale".into(),
                from: None,
              },
              fallback: None,
            }),
          ]),
        })
      }
    }
    _ => {}
  }

  Ok(())
}

[paulm17]

Thanks for taking the time to respond. I really appreciate it!

I have some questions:

Question 1:

One way to solve this is with the into_owned feature. First, you need to enable it in your Cargo.toml.

I did that and this is what I am seeing.

Unfortunately when I save cargo.toml file. There is no into_owned option in the intellisense with vscode. However, if I still put into_owned() and save it. I see in the popup to use:

use lightningcss::traits::IntoOwned;

Is this ok? Or should .into_owned be an actual option? I'm confused on what the best path forward is? 🤔

Question 2:

Ignore what's in the original post. 😄

I've decided to go down the route of mutating the rule. I understand that it is slower, but that's fine. Allows me to have multiple mutations where necessary.

[mischnic]

use lightningcss::traits::IntoOwned;

Is this ok? Or should .into_owned be an actual option? I'm confused on what the best path forward is? 🤔

I hope I understood your problem correctly: to call methods that are implemented for a trait, you have to import that trait.

So you have to both enable that feature in Cargo.toml (as you did) and also import the trait.

[paulm17]

@devongovett @mischnic Thank you for this amazing library and thanks for the help on this question.

I waited a couple of days to ensure that my use case was fully completed to close it.

I've now got a working version and more importantly, now have a greater understanding of both Rust and the library!

Many thanks! 🙏