Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce StyleX for styling #411

Merged
merged 15 commits into from
Jan 24, 2024
Merged

Introduce StyleX for styling #411

merged 15 commits into from
Jan 24, 2024

Conversation

vinceau
Copy link
Member

@vinceau vinceau commented Dec 29, 2023

Description

This PR introduces yet another styling option into our codebase lol. This time it's Facebook's StyleX.

Motivation

Currently we have a lot of different styling options in our codebase:

  1. Emotion
  2. material-ui style overrides via sx
  3. inline style props
  4. plain ol' css

And then even with Emotion, there are different ways to style components e.g.

const SomeComponent = styled.div`
  border: soild 2px red;
`;

or:

const SomeComponent = () => {
  return (<div css={css`border: solid 2px red`}/>)
};

As a developer it's really not clear what we should be using when and where. I'd be nice if we could reduce this list down to just one consistent method we use to style components across the board.

What's wrong with Emotion?

Defining the Emotion styles as string literals, the entire CSS strings are included as is in the compiled JS blob. There are a few issues with this:

  1. There aren't any smarts to deduplicate styles.
  2. There is no syntax highlighting or syntax checking since it's just a string, anything goes.
  3. Increases the size of our renderer.js and means there's more overhead in running and applying the styles.
  4. Applying conditional logic is not straight-forward, and you end up with a lot of messy conditional logic inside of the string

What does StyleX offer over Emotion?

  1. Build-time CSS generation

This is actually huge for performance because all the CSS is generated beforehand at build, so that at runtime it only needs to add/remove classnames. We should see a much better performing application if we switch to StyleX, and even more if we eventually add lazy loading to our pages too (addressed in #412).

  1. Type-safety

Since it uses object notation (similar to the style props and Material's overrides), rather than strings for defining types, we're much less likely to introduce bugs.

Migration Plan

Ideally we start using StyleX on all new components and modifications to existing components. Over time we reduce dependence on Emotion and switch fully over to StyleX for all custom components and styling needs.

End goal: Unfortunately we cannot completely remove Emotion from our codebase since it is a dependency of Material UI. However we can at least stop using it explicitly except for MUI themes and overrides.

@vinceau vinceau marked this pull request as draft December 30, 2023 00:45
@vinceau vinceau marked this pull request as ready for review January 23, 2024 22:22
Copy link
Member

@NikhilNarayana NikhilNarayana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like a solid improvement to me

@vinceau vinceau merged commit 9a08952 into main Jan 24, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants