implement implicit element folding, "as" polymorphic prop #1962

quantizor · 2018-08-31T17:48:08Z

No description provided.

This is basically a reimplementation of the extend API, but implicitly. Folds attrs, styles, and target up so only one component is mounted but all the styles are preserved.

This eliminates the need for the withComponent API by allowing the underlying component that is mounted to be switched out dynamically at runtime, with no changes to the attributed styles.

kitten · 2018-08-31T21:41:48Z

src/models/StyledComponent.js

@@ -219,6 +219,8 @@ export default (ComponentStyle: Function) => {
    options: Object,
    rules: RuleSet
  ) {
+    const targetIsSC = isStyledComponent(target)


nit: Shall we improve the variable name here? e.g. isTargetStyledComp or sth?

Yeah makes sense

kitten · 2018-08-31T21:43:34Z

src/models/StyledComponent.js

+
+    // fold the underlying StyledComponent attrs up (implicit extend)
+    // $FlowFixMe
+    if (targetIsSC && target.attrs) finalAttrs = { ...target.attrs, ...attrs }


I'm starting to think it'd make sense to abstract attrs into a shareable set of utilities or sth... Maybe a future thing.

nit: Btw, I don't think having the lets here makes sense since a ternary would also do the trick and would imply that it won't change later in this fn

kitten · 2018-08-31T21:46:01Z

src/models/StyledComponent.js

+      targetIsSC
+        ? // fold the underlying StyledComponent rules up (implicit extend)
+          // $FlowFixMe
+          target.componentStyle.rules.concat(rules)


Should this be moved to the ComponentStyle constructor itself? i.e.

new ComponentStyle(rules, attrs, id, child)

where the child is another ComponentStyle; This would also move the attrs merging, I guess? Not quite sure why we don't move the bulk of buildExecutionContext there anyway.

Could go either way. Currently ComponentStyle isn't concerned with folding which I think is probably a good thing to separate concerns?

Yea, I was thinking of a "combined" refactor of StyledComponent and ComponentStyle, but that can certainly wait 👍

kitten · 2018-08-31T21:47:27Z

src/models/StyledComponent.js

@@ -271,6 +293,7 @@ export default (ComponentStyle: Function) => {

      const newOptions = {


I think we might not need this anymore, i.e. we can avoid options altogether.

attrs is called before the StyledComponent is created (tagged template literal call) and never again

withConfig is called before as well

extend will go

withComponent will go

So any "cloning" is gone

Let's wait to refactor this out for v5 when withComponent is gone?

Anber · 2018-09-06T13:20:41Z

Hi!

In v3 I can optimize heavy components by extracting dynamic styles to a separated styled``.
Do I properly understand, that In v4 all styles of a component will be rerendered even if a stylesheet of one styled`` would be changed?

const StaticStyledLink = styled.a`
… // a lot of styles
`;

const DynamicStyledLink = styled(StaticStyledLink)`
  color: ${props => props.color};
`;

In the current version color doesn't affect styles of StaticStyledLink, but it will in v4.

quantizor · 2018-09-06T13:36:57Z

In the current version color doesn't affect styles of StaticStyledLink, but it will in v4.

The main change in v4 is the styles of StaticStyledLink will be copied over to DynamicStyledLink and then that color style will be applied last.

Anber · 2018-09-06T14:03:15Z

@probablyup it will be applied, but also all styles will be reapplied and it can be extremely slow in comparison with current v3 behavior.

quantizor · 2018-09-06T14:30:43Z

It all happens in one go. It’s not slow, we test thoroughly.

…

On Thu, Sep 6, 2018 at 9:04 AM Anton ***@***.***> wrote: @probablyup <https://github.com/probablyup> it will be applied, but also all styles will be reapplied and it can be extremely slow in comparison with current v3 behavior. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1962 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAiy1kM4eQ258kMCFXA-JBgXX-P8zib9ks5uYSt5gaJpZM4WVna5> .

Anber · 2018-09-06T15:00:41Z

@probablyup what happens in one go? I don't mean an initial render, I speak about dynamic styles. If I later change color props, new implementation will rerender all styles, and not only styles of DynamicStyledLink how it is now. It's ok if you have just a few styles, but if StaticStyledLink has a complex stylesheet it will definitely affect performance.

mxstbr · 2018-09-06T15:10:48Z

No, StaticStyledLink will not be recomputed I'm 99% sure.

Anber · 2018-09-06T15:17:05Z

@mxstbr but all it styles will be recomputed. After changing just one prop you need to process all styles of DynamicStyledLink and StaticStyledLink, instead of processing just DynamicStyledLink styles.

mxstbr · 2018-09-06T15:21:46Z

No we don't since we know StaticStyledLinks styles are static (ComponentStyle.isStatic) and we never recompute static styles? What am I missing, why do you think that isn't the case?

Anber · 2018-09-06T15:25:44Z

@mxstbr for DynamicStyledLink you generate a new block of styles which also includes all styles from StaticStyledLinks. Then if color is changed, this block (with all styles from DynamicStyledLink and StaticStyledLinks) will be recomputed and reattach to the style node.

mxstbr · 2018-09-06T16:42:19Z

Yeah, <DynamicStyledLink /> will recompute its styling that's true, but any instance of <StaticStyledLink /> won't recompute its style. That's the same as before, any component that has a props interpolation will recompute its styling when re-rendered? I'm still not sure I understand.

Anber · 2018-09-07T10:15:33Z

@mxstbr but now it's possible to reduce the number of styles which will be recomputed by splitting component into two (or more) components: one with static styles (and it will be never recomputed after initial render) and one with interpolated styles. v4, on the other hand, will optimize this two components by merging into one.
For example, DynamicStyledLink now is rendered like <a class="StaticStyledLinks-zxcv DynamicStyledLink-asdf …"></a> and only DynamicStyledLink-asdf will be recompute in case of props changing. In v4 it will be rendered as <a class="DynamicStyledLink-asdf"></a> and any props changing will trigger rerender of whole DynamicStyledLink-asdf which also contains styles from StaticStyledLinks-zxcv.

mxstbr · 2018-09-07T10:38:07Z

@Anber now I understand what you're saying, and I'm happy to say you're way overthinking this: it doesn't matter.

Here's what conceptually happened before before:

// This CSS is static and will never be recomputed
const staticLinkStyles = css`
  color: blue;
  background: red;
`

// This CSS is recomputed every render
const dynamicLinkStyles = css`
  color: ${props => props.color};
`;

Here's what conceptually happens after:

// This CSS is static and will never be recomputed
const staticLinkStyles = css`
  color: blue;
  background: red;
`

// This CSS is recomputed every render
const dynamicLinkStyles = css`
  color: blue;
  background: red;
  color: ${props => props.color};
`;

Sure, a couple extra rules are re-parsed on every render but our parser is so fast it basically doesn't matter. If you're parsing anyway, parsing 5 extra lines is ~0 overhead.

Anber · 2018-09-07T10:59:57Z

@mxstbr if the new parser in v4 is as fast as you say it will be great, but in v3 the trick with component splitting makes sense because render of a complex component with hundred lines of styles takes a noticeable period of time.

mxstbr · 2018-09-07T12:07:42Z

@Anber do you have a benchmark showing the parser to be the bottleneck? I'd be very interested in seeing that. /cc @thysultan

Anber · 2018-09-08T13:31:24Z

@mxstbr I've made a simple example for three cases: static, dynamic and combo dynamic + static. Despite the fact that dynamic + static 15% faster, in absolute numbers the difference is just 10-15 ms. Maybe there are cases where the difference will be bigger, but yes, usually it doesn't matter.

quantizor added 3 commits August 31, 2018 12:45

fold styled(StyledComponent)

05dbb1c

This is basically a reimplementation of the extend API, but implicitly. Folds attrs, styles, and target up so only one component is mounted but all the styles are preserved.

implement "as" polymorphic prop

48710e4

This eliminates the need for the withComponent API by allowing the underlying component that is mounted to be switched out dynamically at runtime, with no changes to the attributed styles.

trim error output

1188463

kitten reviewed Aug 31, 2018

View reviewed changes

address some PR feedback, remove some unused types

26b0a92

kitten approved these changes Sep 1, 2018

View reviewed changes

quantizor added 2 commits September 1, 2018 10:50

implement polymorphism and folding for RN & Primitives

e198207

add changelog entry

6a9009a

quantizor merged commit 60f8a1c into develop Sep 1, 2018

quantizor deleted the as-prop branch September 1, 2018 16:03

gregberge mentioned this pull request Sep 8, 2018

Deprecate component in favor of as smooth-code/smooth-ui#33

Closed

styled-components locked as off-topic and limited conversation to collaborators Sep 8, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

implement implicit element folding, "as" polymorphic prop #1962

implement implicit element folding, "as" polymorphic prop #1962

quantizor commented Aug 31, 2018

kitten Aug 31, 2018

quantizor Aug 31, 2018

kitten Aug 31, 2018

kitten Aug 31, 2018

quantizor Sep 1, 2018

kitten Sep 1, 2018

kitten Aug 31, 2018 •

edited

quantizor Sep 1, 2018

Anber commented Sep 6, 2018

quantizor commented Sep 6, 2018

Anber commented Sep 6, 2018

quantizor commented Sep 6, 2018 via email

Anber commented Sep 6, 2018

mxstbr commented Sep 6, 2018

Anber commented Sep 6, 2018

mxstbr commented Sep 6, 2018

Anber commented Sep 6, 2018

mxstbr commented Sep 6, 2018

Anber commented Sep 7, 2018

mxstbr commented Sep 7, 2018

Anber commented Sep 7, 2018

mxstbr commented Sep 7, 2018

Anber commented Sep 8, 2018

		@@ -271,6 +293,7 @@ export default (ComponentStyle: Function) => {

		const newOptions = {

implement implicit element folding, "as" polymorphic prop #1962

implement implicit element folding, "as" polymorphic prop #1962

Conversation

quantizor commented Aug 31, 2018

kitten Aug 31, 2018

Choose a reason for hiding this comment

quantizor Aug 31, 2018

Choose a reason for hiding this comment

kitten Aug 31, 2018

Choose a reason for hiding this comment

kitten Aug 31, 2018

Choose a reason for hiding this comment

quantizor Sep 1, 2018

Choose a reason for hiding this comment

kitten Sep 1, 2018

Choose a reason for hiding this comment

kitten Aug 31, 2018 • edited

Choose a reason for hiding this comment

quantizor Sep 1, 2018

Choose a reason for hiding this comment

Anber commented Sep 6, 2018

quantizor commented Sep 6, 2018

Anber commented Sep 6, 2018

quantizor commented Sep 6, 2018 via email

Anber commented Sep 6, 2018

mxstbr commented Sep 6, 2018

Anber commented Sep 6, 2018

mxstbr commented Sep 6, 2018

Anber commented Sep 6, 2018

mxstbr commented Sep 6, 2018

Anber commented Sep 7, 2018

mxstbr commented Sep 7, 2018

Anber commented Sep 7, 2018

mxstbr commented Sep 7, 2018

Anber commented Sep 8, 2018

kitten Aug 31, 2018 •

edited