You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My favorite part about emotion (react-emotion) and styled-components is that you can create the element you want and attach the styles to it in one fell swoop. This is extremely convenient and provides a cleaner syntax, helping new developers to pick up the purpose of a component more quickly and contributes to easier maintainability.
Another feature that sort of goes along with styled API is the template literals. This can be interfaced with ReasonML's multiline/interpolation strings {j| $variable |j}. This string can be sent to the Emotion API and handled there, which brings the syntactic benefits of writing actual css in your ReasonML code, Css-in-Re style.
I am sure you (and many others) have thought of this before. I am guessing that the the reason that it not preferred, is that we want our css to be typed and this prevents that from happening. But it just might be worth it for me to get the better syntax.
Thoughts?
The text was updated successfully, but these errors were encountered:
Hey, sorry, I missed your issue. TBH I'm not a big fan of wrapping every <div className=Css.classname /> in custom component. It prolly doable but I never looked into it.
Another feature that sort of goes along with styled API is the template literals. This can be interfaced with ReasonML's multiline/interpolation strings {j| $variable |j}. This string can be sent to the Emotion API and handled there, which brings the syntactic benefits of writing actual css in your ReasonML code, Css-in-Re style.
I am sure you (and many others) have thought of this before. I am guessing that the the reason that it not preferred, is that we want our css to be typed and this prevents that from happening. But it just might be worth it for me to get the better syntax.
Yeah, you are right: the reason why strings are not supported is b/c we're loosing type checking and it basically devalues every single line of this package lol. There's a better way to handle this: https://github.com/astrada/ppx_bs_css It should be possible to add support of this ppx to re-css & Emotion bindings but I have no time for this at the moment. I'm dog-fooding current implementation and add only missed CSS features. Let me know if you want to hack on this.
My favorite part about emotion (react-emotion) and styled-components is that you can create the element you want and attach the styles to it in one fell swoop. This is extremely convenient and provides a cleaner syntax, helping new developers to pick up the purpose of a component more quickly and contributes to easier maintainability.
Another feature that sort of goes along with styled API is the template literals. This can be interfaced with ReasonML's multiline/interpolation strings
{j| $variable |j}
. This string can be sent to the Emotion API and handled there, which brings the syntactic benefits of writing actual css in your ReasonML code, Css-in-Re style.I am sure you (and many others) have thought of this before. I am guessing that the the reason that it not preferred, is that we want our css to be typed and this prevents that from happening. But it just might be worth it for me to get the better syntax.
Thoughts?
The text was updated successfully, but these errors were encountered: