Interesting article! Don't you think that if css variables makes the js ones change, we are breaking the unidirectional dataflow? Usually the changes goes from Js to Css, if we allow the other way around we can have infinite update loops and unexpected changes on the data side (js side) difficult to track.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Yes that's a valid point and well spotted that the flow changes, I think it's a pro in my eyes to be able to inform js from CSS but I have done some testing and there's one thing I haven't got right about my own library 😳 (I need to amend this, we all make mistakes at midnight), since we are watching the style attribute of the given root, the only things that even trigger the observable is something that changes the style attribute, eg devtools or JavaScript, which means that CSS can't trigger a observable callback, unless I did some polling on computed values which I think is maybe an option, but like everything in the library, it's opt in. So the reality is:
only overloaded variables or new variables from the library trigger changes
devtools does too
media queries don't, but match media API will do from the Js side
CSS can update the value of a variable but this will not fire the callback and so is is unaware 😅 going to need to solve this but also il take into account the loop problem
JS can manually get the value of a CSS variable from say a mouse over or resize which kind of sidesteps the problem listed in the point above.
Dilemma resolved?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting article! Don't you think that if css variables makes the js ones change, we are breaking the unidirectional dataflow? Usually the changes goes from Js to Css, if we allow the other way around we can have infinite update loops and unexpected changes on the data side (js side) difficult to track.
Amended the post, thanks for reminding me 😅
Yes that's a valid point and well spotted that the flow changes, I think it's a pro in my eyes to be able to inform js from CSS but I have done some testing and there's one thing I haven't got right about my own library 😳 (I need to amend this, we all make mistakes at midnight), since we are watching the style attribute of the given root, the only things that even trigger the observable is something that changes the style attribute, eg devtools or JavaScript, which means that CSS can't trigger a observable callback, unless I did some polling on computed values which I think is maybe an option, but like everything in the library, it's opt in. So the reality is:
Dilemma resolved?