Scoped CSS styles for live components

msaraiva

Broadway Core Team

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:

How beneficial is using this approach comparing with other solutions?
What are the downsides and limitations?
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.

9 comments

/phoenix #css #liveview #livecomponents

12 3764 9

2023-02-03 09:38:42 UTC

Showing Posts 1 to 9

Show Best Posts
Show All (oldest first)
Show All (newest first)

mhanberg

Expert LSP Core Team

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

Post #1

hauleth

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.

Post #2

mhanberg

Expert LSP Core Team

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.

Post #3

gdub01

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; 
}

Post #4

msaraiva

Broadway Core Team

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

Post #5

coen.bakker

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.

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.

Post #6