4.0 Roadmap

[quantizor]

planned

• drop React 15 support and switch to React 16-compliant lifecycle methods, etc without polyfills
  • use React 16.3+ context API in ThemeProvider (Use new context API #1894)
  • use React.forwardRef API to remove the need for innerRef (use React.forwardRef #1923)
• drop HTML element whitelist
  • desugar syntax via babel plugin (desugar styled.tag to styled('tag') babel-plugin-styled-components#140)
  • add "no-tags" entry (add "no-tags" entry to be used in conjunction with babel plugin #1912)
  • replace imports to "styled-components" with "styled-components/no tags" entry when using the babel plugin (rewrite styled import to "no tags" entry babel-plugin-styled-components#150)
• update documentation to strongly recommend using the babel plugin (emphasize babel plugin usage in the installation & getting started sections styled-components-website#288)
• remove preprocess functionality (Remove preprocess code and flag babel-plugin-styled-components#135)
• drop .extend() API (remove "extend" functionality #1908)
• delete the now unnecessary consolidateStreamedStyles() API (remove deprecated consolidateStreamedStyles API #1906)
• component-based global style API (Component-based API for global styling #1333)
  • remove the injectGlobal API (Component-based API for global styling #1333)
• migrate TS typings out of the repo to DefinitelyTyped (Migrate TS typings to DefinitelyTyped #1778, add styled-components typings DefinitelyTyped/DefinitelyTyped#28207, remove typescript stuff #1922)
• add syntax highlighting support for new APIs (Upcoming API changes in styled-components v4 webstorm-styled-components#55, Upcoming API changes in styled-components v4 stylelint-processor-styled-components#209, Upcoming API changes in styled-components v4 vscode-styled-components#126, Upcoming styled-components v4 changes vim-styled-components#48)
• drop prod builds of things and just let downstream webpack etc handle minification and such
• stop bundling PropTypes with the UMD build (fix removal of PropTypes import in production builds #1921)
• document all new APIs, mark old APIs as deprecated in the docs
• remove jsnext:main from package.json (remove jsnext:main package.json entry point #1907)

nice to have

• generate sourcemaps (Emit source maps #827)
• investigate individual dynamic rule setting in production for perf (Potential performance gains from CSSStyleRule.style #779)
• drop HTML attribute regex + runtime checks
  • add reserved prop (name TBD) (add reserved "sc" prop, handling #1682)
• config (via babel plugin?) for various things like disabling speedy mode, component namespacing, etc

[quantizor]

cc @mxstbr @kitten for commentary and suggestions

[mxstbr]

Global style component?

[quantizor]

Ah yes! Want to add it to the checklist?

[quantizor]

@kitten I wasn't sure if I should add sweetsour to the checklist just yet? I'd love to target a mid-summer release for 4.0, depending on how much time we have.

[mxstbr]

@probablyup 😍😍😍😍😍😍

[mxstbr]

update documentation to strongly recommend using the babel plugin (will be required to use styled.x syntax vs styled('x'))

I'm not a big fan of the bold part.

Instead, we should have the "default" bundle which does ship with the tag list, and then as soon as you install the Babel plugin it transpiles it to use a different entry point without the tag list automatically under the hood:

// ⬇⬇⬇⬇⬇ In ⬇⬇⬇⬇⬇
import styled from 'styled-components';

const Button = styled.button`
  color: blue;
`

// ⬇⬇⬇⬇⬇ Out ⬇⬇⬇⬇⬇
import styled from 'styled-components/no-tag-list';

const Button = styled('button')`
  color: blue;
`

That way, beginner users who are just dipping their toes into styled-components can use it just like all the docs and articles around it suggest without problems, and then once they graduate to using it seriously it should be obvious that you should be using the Babel plugin which automatically gets you huge size gains. We could even do a simple check whether the default bundle was used in production and emit a console.warn("Please use the Babel plugin for massive size savings!").

Potentially we could also sacrifice browser compat in the default bundle and use a proxy, but I'm not a big fan of that simply because create-react-app users won't have a way to opt-into better browser support.

[quantizor]

@mxstbr I kinda see what you're saying but from the perspective of someone using the library, I'd rather be told the correct way to do something from the onset so I didn't have to go back and refactor it all later, you know?

[mxstbr]

@probablyup but it's not a refactoring at all, it's fully automatic? Once you're ready to go full prod mode we recommend you drop in the Babel plugin—you just don't have to use it from the onset.

[migueloller]

Are there any plans to change the innerRef prop to ref and leverage React 16.3 forwardRef?

[quantizor]

@migueloller yup definitely, that's part of the "drop React 15 support and switch to React 16-compliant lifecycle methods, etc without polyfills" item!

[migueloller]

@probablyup Awesome! 😄

[quantizor]

https://github.com/styled-components/styled-components/tree/develop is the 4.0 branch 🎉

First big piece of this is going in soon, thanks to #1894

[alexandernanberg]

I think we can check off the "unsafe async-lifecycles" task after #1894 got merged. Can't find any references to componentWillReceiveProps, componentWillMount or componentWillUpdate anywhere but in the benchmark code (could send in a PR for this but the we might get misleading results compared to master)

I'd also like to add "Use React.forwardRef API" to the checklist, that way we won't have to use a innerRef prop anymore.

Stylis is having an ongoing rewrite so that's something we might want to add in v4 as well

[quantizor]

@alexandernanberg Yup I think that context API work ended up checking off a lot of things! 😄

forwardRef is definitely something we want to do. You're welcome to pick it up if you have time!

[alexandernanberg]

@probablyup Cool! Yeah I'd definitely like to do that when I got some extra time over 😄

Edit: So right now enzyme doesn't support React.forwardRef which blocks us from adding this because it breaks a lot of test. When this PR gets merged and they release a new version we can revisit this. Unless someone has a solution to this.

[Andarist]

👋 From what I understand you are approaching v4 release and I would like to make a proposal for it.

While prop whitelist is obviously non-ideal solution and has its costs (2kb+) the approach is used by more than 1 library, it would be great if we could just use for the time being the same module for it so the cost would be one time thing.

I'd like to propose using is-prop-valid. It's obviously used by emotion, but also by popmotion since recently and I know that if we could all agree on a single module @diegohaz would love to dedupe his copied validAttr from reakit.

Your solution is more correct (i.e. validating post data- characters) but IMHO this is not really needed, the solution without that extreme correctness is "good enough" and is also slightly lighter (~0.5kb from what I remember).

[quantizor]

@Andarist checking it out now

[quantizor]

@Andarist I think we can use it but they're missing some props - going to make an issue now

[Andarist]

Super! Just to add - I have not consulted any other emotion team member on this, just got the ball rolling here. I don't think anyone on the team will have anything against it though.

[ctretyak]

What about new typings for TypeScript like createGlobalStyle ?

[Andarist]

The TS typings were moved out of the repository so that's job for DefinitelyTyped community, not styled-components team.

[LavaToaster]

@ctretyak I'm already on it. 😄 Watch this issue and then within a day after it gets merged it'll be available for use. DefinitelyTyped/DefinitelyTyped#29389

[mxstbr]

Thanks so much @Lavoaster!