styled-components v6

[kitten]

What is this? This is a list of discussions and questions that need answering before we start a v6 complete rewrite and effort. This is for our own notes and transparency but for now I'll lock this issue for a week until we answer some of these questions myself, after which this issue will be unlocked and open for discussion and other members of the CSS-in-JS community that we'll talk to to add their notes and opinions.
So this issue isn't yet (or at all) for general discussion or consumption and is just reflecting our thought process for the time being. More umbrella issues will follow.

What happens to @font-face?

Context: There's a Chrome quirk that reloads fonts and images on each change to the CSSStyleSheet (which is definitely unintended) which can cause a flash of fonts when no cache header has been added. It's also possible that this is already fixed in newer versions. Investigation needed.

Nothing, special behaviour could still remain dropped, although it's possible we could have a workaround that directly mutates the inserted @font-face at-rule to swap out the URL with something else in development to make this issue less apparent.

What happens to @import?

Nothing, special behaviour could still remain dropped, although a warning would be welcome.

Do we support IE11 in v6?

It'd be great to drop IE11 and this may just now be possible since people could stop upgrading when they need IE11 support since v4/v5 have been relatively stable (as long as we still patch bugs)

Do we start with a rewrite?

Current Answer: A TypeScript rewrite would be welcome. We can still auto-generate typings for Flow and Flow in general is "falling out of popularity." Meanwhile a TypeScript rewrite is just ergonomically nicer for ourselves.

Currently we believe that a rewrite to get rid of old legacy code paths and questionable implementation details is the way forward.

What happens to the style system?

We can split out our style management system into a separate non-React subpackage that is usable by other libraries so that other style systems can better cooperate with styled-components.

Is our specificity approach ripe for an upgrade?

In the current systems we have an elaborate system that ensures that style ordering is predictable and solid because of composition. This is really important, but hinders optimisations for static styles. It's possible that we may be able to come up with more or better solutions for this. Investigation needed.

What about atomic rules?

In theory atomic rules in production could help with a lot of optimisations. However that means we'll have to ensure that it runs identically to a non-atomic system in terms of specificity and ordering.

Targeting other components or using + & would also still need component IDs, so Investigation needed.

What about bundle size?

Just by getting rid of the TextNode fallback / alternative and using Proxy for the styled aliases we'd get rid of a large chunk of complexity.

In theory the $ prefix, i.e. $variant syntax would get rid of prop filtering too.

Do we utilise new approaches around CSS Custom Properties?

With the above we should also put this up for a question. If we split styling up into static and dynamic parts we could even split that static parts into value changes that can be expressed with custom properties.

That being said, if we do want to do this, our specificity and ordering approach will break!

What about our theming system?

Even in a TypeScript rewrite this will be an issue as no type can be spread out via the ThemeProvider. So either we need a factory here or another system that distributes the theme type better. Investigation needed.

What about ENV-based switches?

Apart from NODE_ENV: 'production' | 'development' no switch should be required. We moved to SSR having its own StyleSheetManager and it's highly likely that no other switch will be needed to prefer client v server logic anymore. So no typeof checks on globals should be performed in v6.

This list is still incomplete

[OKNoah]

There's also react-native-macos maintained by Microsoft. Most of their attention seems to be on Windows, and it seems usable only with very old versions of things (react-nativgation@1.0.0-beta.11) and not styled-components/native from what I can tell.

[corysimmons]

@kitten @mxstbr What are your thoughts on getting https://spectrum.chat/styled-components/general/feat-req-add-prop-to-allow-for-encapsulating-selectors-to-component~1ec08108-05df-41f7-b8a3-08d99751c6ea into the new version of styled-components? I've been wanting to do this since I started using styled-components years ago. 😿

[motevallian]

Can we have a better support for micro-frontends?
Ideally styled-components could be freely be bundled any number of times on the page by any number of apps. It might generate duplicate styles but has a first-class solution for scoping/isolating classnames for each app that loads styled-components.

[kitten]

@motevallian I mean, I'd love for that to happen, however it ain't going to happen unless the boundaries of apps is clear. So for instance, if we allow the StyleSheetManager to define a "token" that is assigned to each style tag it generates then we can do it. With SSR/prerendering this is necessary because it may split up style tags if it's streamed (which is often preferable). But it can never be automatic.

Generally, this is why I'd recommend people to set up federate micro-frontends with shared instance of React, React DOM, styled-components, [all things that are needed globally]. Ultimately that means you're sharing the "brunt force" of all vendored libraries. Obviously, that depends also on your approach and it isn't always possible to federate and build at once, or at least, to share even a few dependencies at all times.

Because of that we also considered sharing the sheet code in a separate package. That means that more libraries could access a shared sheet and that the sheet logic itself could deduplicate itself on a global variable. I still think no matter what we add, this is really worth doing as the sheet interface has remained stable for a long time (and likely will) and if we keep it stable that does solve all our problems.

Apart from that, if we do encounter breaking sheet changes, we can still fall back to adding special "version tags" to the tag output and global variable, and all other efforts for federation/multi-SC on a page could be layered on top of this measure, i.e. in styled-components rather than the sheet.

cc @probablyup: Wdyt? I can likely make sure that we make a separate sheet library. I can send a DM soon so we can discuss the details that aren't interesting beyond this thread

[tim-soft]

I would love to see better typescript support around theming, particularly when nesting themes

[kimgiutae]

I would love to see better typescript support around theming, particularly when nesting themes

I can confirm this also. The autocomplete support is not working well in some styled components with ThemeProvider.

Hmm... after some research I found that I had to declare and export the DefaultTheme interface in a styled.ts file in order to activate autocomplete. I didn't try it but I think that that is the solution. (https://medium.com/rbi-tech/theme-with-styled-components-and-typescript-209244ec15a3)

[mbergeronupgrade]

There is currently some hype around build-time css-in-js due to performance. Any hope this concept could be integrated into styled-components?

See https://pustelto.com/blog/css-vs-css-in-js-perf/ for context.

[kitten]

I think most of this is becoming clearer now.

What happens to @font-face?

This is related to a Chromium issue, and as it's browser specific it may not be wise to work around it: https://bugs.chromium.org/p/chromium/issues/detail?id=1216451

What happens to @import?

Unchanged situation / limited support. See #3146

Do we support IE11 in v6?

We likely will drop IE11 support in v6. There'll be no special effort to support it anymore, but similarly there'll be no special effort needed to drop support. Currently, for us this does mean dropping the non-CSSOM sheet implementation. A refactor could then make it a bit more compact.

Do we start with a rewrite?

Work on main is currently underway to migrate to TypeScript. There'll be special considerations for type inference, which we can hopefully adopt from definitely-typed. Implementing #1874 could help here.

What happens to the style system? (extract sheet code)

Depends on the prior TypeScript refactor and dropping IE11 support. This can likely be parallelised.

Micro frontends: If we extract the styling/sheet system, there's a chance we can improve how styles are shared by sharing the underlying system and tags. This requires the extraction of the system first, and we'd need some input from people working on module federation and micro frontends. However, in general, there's a lot we can improve here.

Is our specificity approach ripe for an upgrade?

Not really. It does work correctly, however folding and & expansion is causing a lot of confusion, so those will have to be revisited before we consider other changes.

We may want to find ways to limit the impact of the aforementioned Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1216451

What about atomic rules?

Not considered for v6 / no discussion occurred, as this would've been a major change of our approach.

Do we utilise new approaches around CSS Custom Properties?

This would need some kind of parser. It's unlikely that we'll find a way to shoehorn this into the library, unless we can build on some stylis upgrades. However, this would mean specificity changes, so for now, this isn't in scope for v6 at least.

What about bundle size?

The refactors listed should help us implement this. Our build pipeline needs a desperate upgrade, but I'll likely address this as we go.

What about ENV-based switches?

See above; very much build system related. There's some refactors we can do around our error system and such due to the TypeScript refactor.

[gregberge]

Should we take care of this for v6? reactwg/react-18#110

[iamstarkov]

There was a v6.0.0-beta.6 published @lunaris just yesterday. Which is good.

I can't seem to find relevant umbrella issue for v6 release as a whole with ETA and react 18 support mentioned anywhere. Can anyone point me in the right direction?

[quantizor]

There’s a pinned issue for v6 beta. No current ETA, but I’m hoping to have a RC ready by the winter holidays at the latest.

I have not spent much time considering React 18 to be honest, if there’s someone that wants to pitch in for the server-side changes that would be helpful.

[quantizor]

That being said, we are using useInsertionEffect for cGS where available