RFC: useWithThemedStyles hook, simplifying CSS in JS

[vibdev]

🚀 RFC

Replace styled components with a purpose build method that will improve developer experience, provide a consistent theme, and perhaps most importantly make upgrading/migrating css libraries much simpler.

Motivation

1. Abstract away emotion so consumers don't have to manage the dependency. This will also allow organizations using CKR to more easily update major versions. Consumer can update emotion just by updating CKR and will not have to worry about manually changing every component every major release.

2. Provide a painless way to apply a theme giving benefits like RTL automation for free. useWithThemedStyles will automatically apply the theme similar to the current styled wrapper in CKR.

3. Provide an alternative to using styled components. Styled components obscure html markup, obscure what is actually a component vs just a plain html tag with style, can be very difficult to read, and are slow. useWithThemedStyles will provide an easy way to use string or object based styles.

4. Provide a more performant way of applying dynamic styles. Using emotion for highly dynamic styles, e.g. changing height based on scroll position, is extremely inefficient. useWithThemedStyles will provide a simple way to denote dynamic styles and will apply them directly to an element instead of running through emotion.

MVP Example

https://codesandbox.io/s/upbeat-sun-3u9od?file=/src/withStyles.js

[anicholls]

Thanks for the proposal @vibdev! Overall, I like the direction and intention of this. We definitely need a way to provide consumers with an easier way to do RTL styling. Here are a few thoughts:

• I'm on the fence about the abstraction of the application of styles. I see the value of abstracting our css-in-js dependency so it's easier to manage, but to get true value out of this, everyone will need to be using our hooks and that could be hard to enforce. I also think people will prefer a less "black-magic" way of applying styles by setting the css and style props themselves. It's not too bad for withStyles, but it quickly becomes unclear with withDynamicStyles. I think this will be a delicate balance between abstraction for upgrading's sake, and giving consumers the DX they expect/desire.
• I would love to do a poll of our consumers to see if we offered this, whether they would use it for everything. It's definitely a departure from styled components which folks have come to rely on pretty heavily.
• I know we discussed where this should live, and I would definitely expect it to be in CK
• re. the specific API naming, I think the combination of use and with is a bit confusing. with hearkens back to HOC, which aren't at play here. I think this could be improved, but would love to get your thoughts here.

[vibdev]

Hi @anicholls thanks for the feedback would defiantly love to discuss how to make this easier for people to use.

• I think this one is tough because we do need to run the css through some sort of function to get the automatic rtl conversation. This is important for dynamic styles too so I am not sure the best way to make that process more simple and less 'black boxy'. There is going to be a push, at least internally, to have standard method of help to guarantee rtl support so I think the team responsible for that will help drive usage.
• I think giving folks the option of using object, tagged templates, or styled api is a good consideration esp if we want to up adoption. While I have major problems with the styled api I think some of the upsides such as theme application and easier updates outweighs it.
• Great to hear, would be ok starting in labs too if we want to bulletproof the api over the 5.x release cycle
• yep totally agree there, it wasn't originally a hook so we went with 'with' but then when we pulled in CKRs useTheme we have to hookify it.

[NicholasBoll]

My biggest concern is raising the bar for minimum environment when it comes to examples. Right now, our minimum environment is bundler + JSX transformer (something that understands import statements and JSX). With Typescript supporting JSX out-of-the-box, this ended up being a low threshold.

This hook relies on a transparent use of css which means a consumer of our example will have to understand what the css prop is and how to set up their environment to use it correctly. If a project is built using babel, that transformation can be transparent, but there is nothing for Typescript.

Our examples could always do the following:

/** @jsx jsx */
import {jsx} from '@emotion/core';

I don't think copy/pasting that into an environment with the babel transform will cause a problem.

[anicholls]

@vibdev

I think this one is tough because we do need to run the css through some sort of function to get the automatic rtl conversation. This is important for dynamic styles too so I am not sure the best way to make that process more simple and less 'black boxy'. There is going to be a push, at least internally, to have standard method of help to guarantee rtl support so I think the team responsible for that will help drive usage.

I didn't mean to say that a theme-based RTL function was "black boxy" - that's definitely needed. I was referring to the way that the hook spreads both attributes, which looks a bit foreign at first glance.

I realize this removes the Emotion abstraction, but I think most developers would be more comfortable with something like this:

<div css={useThemeRTL(myStyles)}  style={useThemeRTL(myDynamicStyles)} >

It's a lot more obvious what this is doing at first glance IMO

[vibdev]

@anicholls I think that is a good middle ground. Clients up-taking CKR's useThemeRTL could always abstract things away into one file. Maybe we could just give an example how to do it similar to how we give examples for compound components.

[anicholls]

@vibdev Sounds like a good compromise 👍

How do you feel about contributing useThemeRTL to the prerelease/v5 branch?
Note: we've merged #992, so the directory structure will look a little different. Can you put it in modules/labs-react/common? This will require a new module since we don't have a labs common ATM. You can use yarn create-component for this.

[vibdev]

@anicholls can do 👍

[vibdev]

PR: #1041