Scoped CSS styles for live components

Hi folks!

I wonder if any of you have already tried to implement scoped CSS styles for live components. I’m specifically interested in how would be the best way to handle dynamic styles (styles that need to be updated when a related assign changes).

This feature seems to be quite popular among frontend devs using React and friends. It’s also one of the most requested features for Surface.

I was reluctant to implement something like that on top of LV but after talking to a few people I was convinced that this might be a good fit for live components.

An initial proposal has been submitted along with a PoC project, so if you’re interested in the subject, feel free to give it a try and share your thoughts.

Some questions I still have:

  1. How beneficial is using this approach comparing with other solutions?
  2. What are the downsides and limitations?
  3. Should/could this be implemented as a separate lib so any project using LiveView could benefit from?

In case you’re curious, here’s how it looks like:

Full source code can be found here.

Cheers.

12 Likes

Not related to the actual topic, but I wishing Elixir had named heredocs, so syntax highlighting that like that would be easier :smile:

That is why we have sigil for. (Un)fortunately for now these are limited to single characters, but I remember proposal to allow multi-character sigils.

Yeah, but for what I’m referring to, the name has no effect on the string. It’s just a name for the string, that your editor can use to do some highlighting.

Sigils are macros that need to be implemented, and imported, which is unnecessary.

My only feedback is that this looks awesome =)

Separating the static and dynamic parts is phenomenal in terms of optimization.

Having styles locally scoped is also amazing.

Having the option to apply a function to it is also great. I’m thinking of a theme option where you can pass ‘primary’ as a dynamic color and lookup a user’s setting to get what their primary color actually is potentially.

The only question I have is regarding the var(--my-color). If I define a global root var like ‘primary-color’ outside of surface/scoped styles, and don’t pass a style var, I’m still able to use it like border: solid 3px var(--primary-color) and it’ll pick up the globally set css variable of:

:root {
  --primary-color: coral; 
}

?

2 Likes

Yup. If the variable is not listed in vars, it will take the global value.

1 Like

Any updates regarding your thoughts about bringing or not bringing scoped styles to the core of Surface? It has been some time since the Github proposal was closed. And full disclosure: I was pretty thrilled initially to see this proposal. :nerd_face:

Edit: Just realized there is a ‘css-parser’ branch in Surface’s GitHub repository. See plenty of recent commits. Thank you for all the great initiatives/work and looking forward to the new features.

1 Like

Yes, please. Automatically scoped CSS is one of the best features of Svelte, for example, and saves you from many headaches.

1 Like

An update on that can be found here Scoped CSS by msaraiva · Pull Request #621 · surface-ui/surface · GitHub.

2 Likes

Resurrecting this topic :slight_smile:

Is there a plan to bring scoped CSS styles to LiveView components (without Surface)?

Are there any good workarounds?

Cheers!

7 Likes