styled-components/styled-components

4.0 Roadmap

quantizor opened this issue · 23 comments

quantizor commented

planned

nice to have

  • generate sourcemaps (#827)
  • investigate individual dynamic rule setting in production for perf (#779)
  • drop HTML attribute regex + runtime checks
    • add reserved prop (name TBD) (#1682)
  • config (via babel plugin?) for various things like disabling speedy mode, component namespacing, etc
quantizor commented

cc @mxstbr @kitten for commentary and suggestions

mxstbr commented

Global style component?

quantizor commented
quantizor commented

@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 commented

@probablyup 😍😍😍😍😍😍

mxstbr commented

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 commented

@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 commented

@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 commented

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

quantizor commented

@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 commented

@probablyup Awesome! 😄

quantizor commented

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 commented

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

  • 👍4
quantizor commented

@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 commented

@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.

  • 👍1
Andarist commented

👋 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).

  • 👍4
quantizor commented

@Andarist checking it out now

quantizor commented

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

Andarist commented

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 commented

What about new typings for TypeScript like createGlobalStyle ?

Andarist commented

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

  • 👍1
LavaToaster commented

@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

  • 👍3
  • 🎉3
mxstbr commented

Thanks so much @Lavoaster!