shouldForwardProp support #3006

stevesims · 2020-02-07T13:37:56Z

Following discussion elsewhere, such as on #2780, re-opening this PR (previously #2392)

adds support for use of shouldForwardProp config method, which can be used to explicitly determine which props should be forwarded on
if this config is not provided then existing functionality is preserved (i.e. all props passed to components, or for HTML elements check using validAttr)

Inspired by the same feature in emotion

Resolve #439
Resolve #2878

stevesims · 2020-02-07T13:38:59Z

Code now re-worked a bit and rebased on current master

diondiondion · 2020-02-07T15:11:51Z

Does this support statically forwarding the as prop, too?

In other words, will a component as defined below pass the as prop on to the wrapped styled component without having to use the forwardedAs prop instead?

const Comp = styled(AnotherStyledComponent).withConfig({
  shouldForwardProp: prop => ['as'].includes(prop)
})`
  /* ... */
`;

penx · 2020-02-07T16:12:02Z

@diondiondion what would a unit test look like for that? Something like this?

    it('supports statically forwarding the as prop', () => {
       const StyledDiv = styled('div')`
         color: red;
       `;
       const StyledDiv2 = styled('div')`
         color: blue;
       `;

       const ComposedDiv = styled(StyledDiv).withConfig({
         shouldForwardProp: prop => !['as'].includes(prop)
       })`
  /* ... */
`;
       const wrapper = TestRenderer.create(<ComposedDiv as={StyledDiv2} />);
       const { props } = wrapper.root.findByType('div');
       // expect ?
     });

stevesims · 2020-02-07T16:26:03Z

@diondiondion good question - and to be honest, I'm not sure. I did wrote some tests concerning how as works, but I'm not entirely sure they cover what you're asking about. Unfortunately I don't have the time to check on this right now, and won't until Monday at the earliest.

quantizor · 2020-02-07T21:12:41Z

Fwiw we would not deprecate forwardedAs so might not be an issue

…

On Fri, Feb 7, 2020 at 11:26 AM Steve Sims ***@***.***> wrote: @diondiondion <https://github.com/diondiondion> good question - and to be honest, I'm not sure. I did wrote some tests concerning how as works, but I'm not entirely sure they cover what you're asking about. Unfortunately I don't have the time to check on this right now, and won't until Monday at the earliest. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3006?email_source=notifications&email_token=AAELFVU25JC5GJ226KFYSX3RBWDR5A5CNFSM4KROUCCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELDT3NQ#issuecomment-583482806>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELFVVBLE7FFGSC6FUDTT3RBWDR5ANCNFSM4KROUCCA> .

diondiondion · 2020-02-08T16:18:37Z

I realise now that the example in my previous question had a typo in it, it was set up to prevent the as prop from being passed on. I've edited it now.

what would a unit test look like for that? Something like this?

@penx Let's use an intermediate JSX component as an example as that's the most likely real world use case I can think of.

it('supports statically forwarding the as prop', () => {
	const Clickable = styled('a')`
		background-color: pink;
	`;
	const Button = ({as, className, children}) => (
		<Clickable as={as} className={className}>Hello {children}</Clickable>
	);

	const MenuButton = styled(Button).withConfig({
		shouldForwardProp: prop => prop === 'as'
	})`
		margin-right: 4px;
	`;

	const wrapper = TestRenderer.create(<MenuButton as="button">world</MenuButton>);
});

Given this example, I'd expect The rendered component's

element type to be "button"
text content to equal "Hello world"
styles to be background-color: pink; margin-right: 4px;

Fwiw we would not deprecate forwardedAs so might not be an issue

@probablyup In my mind forwardedAs has one valid use case – when it's used at the same time as the as prop.

However, the scenario where you have to use it instead of the as prop because not doing so would break the component or its styles is why I'm advocating for it. In those cases, forwarding the as prop statically would be a MUCH safer option. The lack of this ability creates inconsistent component APIs that unnecessarily require knowing the internals of a component.

quantizor · 2020-02-08T16:19:31Z

We’re not making subtractive API changes at this point so we can re-evaluate at a later date

…

On Sat, Feb 8, 2020 at 11:18 AM diondiondion ***@***.***> wrote: I realise now that the example in my previous question had a typo in it, it was set up to *prevent* the as prop from being passed on. I've edited it now. what would a unit test look like for that? Something like this? @penx <https://github.com/penx> Let's use an intermediate JSX component as an example as that's the most likely real world use case I can think of. it('supports statically forwarding the as prop', () => { const Clickable = styled('a')` background-color: pink; `; const Button = ({as, className, children}) => ( <Clickable as={as} className={className}>Hello {children}</Clickable> ); const MenuButton = styled(Button).withConfig({ shouldForwardProp: prop => prop === 'as' })` margin-right: 4px; `; const wrapper = TestRenderer.create(<MenuButton as="button">world</MenuButton>); }); Given this example, I'd expect The rendered component's - element type to be "button" - text content to equal "Hello world" - styles to be background-color: pink; margin-right: 4px; Fwiw we would not deprecate forwardedAs so might not be an issue @probablyup <https://github.com/probablyup> In my mind forwardedAs has one valid use case – when it's used at the same time as the as prop. However, the scenario where you *have* to use it *instead of* the as prop because not doing so would break the component or its styles is why I'm advocating for it. In those cases, forwarding the as prop statically would be a MUCH safer option. The lack of this ability creates inconsistent component APIs that unnecessarily require knowing the internals of a component. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3006?email_source=notifications&email_token=AAELFVWK5GDRPLKLA7YEFATRB3LN5A5CNFSM4KROUCCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELFVNWQ#issuecomment-583751386>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELFVWBTOHV53B7CGJR3CDRB3LN5ANCNFSM4KROUCCA> .

diondiondion · 2020-02-08T16:27:07Z

Not sure how this is a "subtractive API change", but alright. But wouldn't not introducing this capability from the get go make adding it later a potential breaking change? It seems like that's how it should work. shouldForwardProp: prop => prop === 'as' reads pretty obvious to me.

kitten · 2020-02-13T00:53:28Z

packages/styled-components/src/models/StyledComponent.js

@@ -180,6 +192,20 @@ function useStyledComponentImpl<Config: {}, Instance>(
  return createElement(elementToBeCreated, propsForElement);
 }

+function getShouldForwardProp(options, target, isTargetStyledComp) {


nit: Let's maybe keep this inlined next to finalAttrs for the sake of having them all in one place. I'd argue we can clean this up in a separate refactor PR and get rid of some of the legacy stuff in this file.

kitten · 2020-02-13T00:54:24Z

packages/styled-components/src/models/StyledComponent.js

@@ -75,6 +75,7 @@ interface StyledComponentWrapperProperties {
  displayName: string;
  foldedComponentIds: Array<string>;
  target: Target;
+  shouldForwardProp: Function;


We can introduce a type for this, since it's just (prop: string) => boolean let's also remember that this is optional and may be undefined

kitten · 2020-02-13T01:00:49Z

packages/styled-components/src/models/StyledComponent.js

+  //     i.e. Don't pass through non HTML tags through to HTML elements
+  // else (we're on a component - pass through all by default)
+  //   () => true
+  const shouldReallyForwardProp = shouldForwardProp || (


I think the comment here is redundant if this was a little clearer in the first place 😅

If we do a little refactor we can clean this up and make what's going on a lot clearer.

shouldFilterProps could be reverted and we can remove isTargetTag from it.

then wee can introduce a separate variable: const propFilterFn = shouldForwardProp || (isTargetTag && validAttr);.

if (shouldFilterProps) becomes if (shouldFilterProps || propFilterFn)

Then shouldReallyForwardProp(key) (which btw has unnecessary parens) can be replaced by: (!propFilterFn || propFilterFn(key))

lastly we can now rename shouldFilterProps to shouldFilterComputedProps

done - was a little bit more involved, but essentially followed your suggestions - also didn't rename shouldFilterProps cos that didn't feel entirely worth it 😁

kitten · 2020-02-13T01:02:15Z

packages/styled-components/src/models/StyledComponent.js

+    return target.shouldForwardProp;
+  }
+
+  return options.shouldForwardProp;


@probablyup This can probably be done separately but we can totally add shouldForwardProp as a shortcut to replace the manual withConfig, right? Just to have alignment with Emotion.

I'd also argue now that we're touching filtering props, "transient props" (props that are always filtered) could also be revived after merging this. (Ref: #2093)

adds support for use of `shouldForwardProp` config method, which can be used to explicitly determine which props should be forwarded on if this config is not provided then existing functionality is preserved (i.e. all props passed to components, or for HTML elements check using `validAttr`) Inspired by the same feature in emotion

@kitten

following feedback from @kitten, `shouldForwardProp` now has a proper flow-type definition refactor how `shouldForwardProp` is used to make code slightly clearer code to compose `shouldForwardProp` now in-lined into `createStyledCompontent`

kitten · 2020-02-14T11:00:07Z

packages/styled-components/src/models/StyledComponent.js

+      // $FlowFixMe
+      shouldForwardProp = prop => target.shouldForwardProp(prop) && options.shouldForwardProp(prop);
+    }
+    ({ shouldForwardProp } = target);


This doesn’t seem right maybe, 🤔 was this supposed to be in an else statement?

nit: Also can we drop the destructuring here please? We’re also not destructuring for the arrow function composition above, so let’s maybe settle on one pattern for both?

heh - i didn't want to use destructuring here - eslint complained at me 😉 happy to drop

and yes - should have had an else in there - good spot 😁

kitten

This is looking amazing! 👏 thanks for the time to submit this and to get it updated ♥️

Once we’ve got this merged I hope we can internally discuss and move on to add a shortcut replacing the manual usage of withConfig. I hope to be able to merge this later today 🍀

ajkl2533 · 2020-02-18T09:10:11Z

Hi there do you have any timeline when this will be released?

stevesims · 2020-02-18T10:43:17Z

@diondiondion FYI i've not been ignoring your question, and have looked into it quite deeply.

There's an issue with the test that you've proposed:

it('supports statically forwarding the as prop', () => {
	const Clickable = styled('a')`
		background-color: pink;
	`;
	const Button = ({as, className, children}) => (
		<Clickable as={as} className={className}>Hello {children}</Clickable>
	);

	const MenuButton = styled(Button).withConfig({
		shouldForwardProp: prop => prop === 'as'
	})`
		margin-right: 4px;
	`;

	const wrapper = TestRenderer.create(<MenuButton as="button">world</MenuButton>);
});

Given this example, I'd expect The rendered component's

element type to be "button"
text content to equal "Hello world"
styles to be background-color: pink; margin-right: 4px;

The problem is that by providing an as prop to MenuButton you're telling that component to use a different component to render than the specified Button component. As a result your text content will be just world, with only the margin-right style applied.

Without using forwardedAs, the only way for the system to know that it should ignore the as prop being passed to MenuButton would be if the passed in shouldForwardProp function is analysed to see what it does when presented with an as prop. This doesn't feel entirely wise to me.

It seems to me that the current forwardedAs approach is the best compromise to this issue.

diondiondion · 2020-02-18T11:28:18Z

FYI i've not been ignoring your question, and have looked into it quite deeply.

@stevesims No worries, thanks for looking into it.

The problem is that by providing an as prop to MenuButton you're telling that component to use a different component to render than the specified Button component.

Yes, but that's exactly the point of my request. I want to be able to tell styled-components that MenuButton should never "act" on the as prop and instead directly forward it to the Button component that it wraps (see #2129 for more detail).

The shouldForwardProp option sounds to me like it should be able to handle this, but maybe it's not the right tool for the job. (In which case we'd need an additional option, something like ignoreAs or allowAs like in astroturf; but that'd be a discussion for another place).

Without using forwardedAs, the only way for the system to know that it should ignore the as prop being passed to MenuButton would be if the passed in shouldForwardProp function is analysed to see what it does when presented with an as prop. This doesn't feel entirely wise to me.

Isn't every prop passed to the shouldForwardProp function? I thought the complexity came from making sure that when the as prop is not handled in shouldForwardProp, the current behaviour stays the same, but it didn't seem like an unsurmountable problem.

Steveeeie · 2020-02-21T11:25:53Z

Any updates on when this will be released?

Steveeeie · 2020-02-24T12:38:21Z

Martinnord · 2020-02-27T08:57:50Z

I feel with @Steveeeie. Any plans on this being released soon?

lucastobrazil · 2020-02-29T20:59:37Z

Ppppplllleeease can we merge this? i was about to start migrating to Emotion for this very reason but already started missing the feel of s-c.

aulneau · 2020-03-04T19:08:24Z

I've been hoping for this feature to be implemented for so long, would absolutely love to see it merged! Thanks for all the work on this.

lucastobrazil · 2020-03-04T22:49:02Z

@kitten sorry for ping but we have a lot of excited people here. Anything we could do to help get it merged? Docs need to be written or anything?

quantizor · 2020-03-05T20:30:08Z

@lucastobrazil Yes a PR for the website to add this API documentation would be great. I think this is ready to be merged though.

Someone will also need to work on the typing implementations for TS and Flow.

quantizor · 2020-03-05T20:56:12Z

We also need a PR for StyledNativeComponent with the same changes.

peduarte · 2020-03-05T21:11:29Z

Ohhhh yes! So so so happy about this. Thank you everyone for your work <3

lucastobrazil · 2020-03-05T22:46:49Z

Just trying this out locally - based on the tests written, i've tried doing this:

const Box = styled.div.withConfig({
  shouldForwardProp: prop => !['font-family'].includes(prop)
})(
  { boxSizing: 'border-box' },
  compose(
    space,
    // ...
  )
);

But it doesn't seem to call the withConfig method?

Martinnord · 2020-03-06T11:32:18Z

I'm facing the same issue as @lucastobrazil. Is it something we are missing?

lucastobrazil · 2020-03-08T10:12:34Z

@Martinnord I managed to get it working with the local styled components sandbox app that is bundled with the mono repo. Following the example in the test it worked.

Was trying to use yarn link to link my project locally to this package, but it was failing.

Do we have any visibility into the release plan for the next official npm release with this feature in it?

Steveeeie · 2020-03-16T12:54:54Z

@probablyup Are you able to give an update as to when this will be part of a release?

quantizor · 2020-03-16T12:56:11Z

Near future. There’s an SSR bug I’m looking to resolve before cutting 5.1

…

On Mon, Mar 16, 2020 at 8:55 AM Steve Meredith ***@***.***> wrote: @probablyup <https://github.com/probablyup> Are you able to give an update as to when this will be part of a release? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3006 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELFVQNZ3CAT4LPUK3IYD3RHYOTBANCNFSM4KROUCCA> .

tuck2002 · 2020-03-30T18:00:14Z

Near future meaning? Rebuilding a component library with Styled System and this is my biggest hang up at the moment.

Steveeeie · 2020-04-01T10:52:07Z

@probablyup can we get an update on when this will be released?

Martinnord · 2020-04-06T10:50:46Z

aulneau · 2020-04-06T17:08:47Z

@probablyup anything we can do to help? seems like a lot of folks are waiting for this and would probs be happy to assist :)

quantizor · 2020-04-06T19:56:04Z

I was waiting on #3061 but I think I'll just cut a release later tonight since it's taking a while.

StevenLangbroek · 2020-04-06T20:04:05Z

Yeah sorry I wouldn't wait on that, need to figure out what the hell is going on before I can submit a fix, and since it is a fix we can cut a patch when it's ready.

peduarte · 2020-04-06T20:16:49Z

Great team effort everyone 👏

quantizor · 2020-04-07T05:34:13Z

Out in 5.1, thanks everyone for pitching in! https://github.com/styled-components/styled-components/releases/tag/v5.1.0

kachkaev · 2020-04-07T16:01:35Z

Discussion of typings for this new feature: DefinitelyTyped/DefinitelyTyped#43693

stevesims force-pushed the feat/should-forward-prop branch from 4072f9d to 1cbf75a Compare February 7, 2020 14:11

stevesims requested a review from kitten February 7, 2020 14:13

penx mentioned this pull request Feb 7, 2020

Add support for shouldForwardProp #2392

Closed

This comment has been minimized.

Sign in to view

This was referenced Feb 9, 2020

Add new param shouldForwardProps to allow the passing in of 'invalid' attributes #2780

Closed

RFC filtering forwarded props #2878

Closed

This comment has been minimized.

Sign in to view

karlhorky mentioned this pull request Feb 9, 2020

Separate HTML attributes from styling props #439

Closed

kitten reviewed Feb 13, 2020

View reviewed changes

Steve Sims and others added 2 commits February 14, 2020 08:25

refactor of shouldForwardProp support

94b2d76

following feedback from @kitten, `shouldForwardProp` now has a proper flow-type definition refactor how `shouldForwardProp` is used to make code slightly clearer code to compose `shouldForwardProp` now in-lined into `createStyledCompontent`

stevesims force-pushed the feat/should-forward-prop branch from 1cbf75a to 94b2d76 Compare February 14, 2020 10:23

kitten reviewed Feb 14, 2020

View reviewed changes

minor logic tweak following review

10fbefc

kitten approved these changes Feb 14, 2020

View reviewed changes

seeden mentioned this pull request Feb 15, 2020

remove property when it is used as variant styled-components/xstyled#99

Closed

quantizor merged commit e02109e into styled-components:master Mar 5, 2020

peduarte mentioned this pull request Mar 6, 2020

shouldForwardProp - or export all propNames? radix-ui/design-system#163

Closed

Pytal mentioned this pull request Mar 17, 2020

Add shouldForwardProp method callstack/linaria#555

Closed

BJvdA mentioned this pull request Mar 20, 2020

[rfc] move from styled-components to emotion storyofams/next-boilerplate#13

Closed

styled-components locked as resolved and limited conversation to collaborators Apr 7, 2020

shouldForwardProp support #3006

shouldForwardProp support #3006

Conversation

stevesims commented Feb 7, 2020 • edited by kitten Loading

stevesims commented Feb 7, 2020 • edited Loading

This comment has been minimized.

diondiondion commented Feb 7, 2020 • edited Loading

penx commented Feb 7, 2020 • edited Loading

stevesims commented Feb 7, 2020

quantizor commented Feb 7, 2020 via email

diondiondion commented Feb 8, 2020

quantizor commented Feb 8, 2020 via email

diondiondion commented Feb 8, 2020

This comment has been minimized.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kitten Feb 13, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kitten left a comment

Choose a reason for hiding this comment

ajkl2533 commented Feb 18, 2020

stevesims commented Feb 18, 2020

diondiondion commented Feb 18, 2020

Steveeeie commented Feb 21, 2020

Steveeeie commented Feb 24, 2020

Martinnord commented Feb 27, 2020

lucastobrazil commented Feb 29, 2020

aulneau commented Mar 4, 2020

lucastobrazil commented Mar 4, 2020

quantizor commented Mar 5, 2020 • edited Loading

quantizor commented Mar 5, 2020

peduarte commented Mar 5, 2020

lucastobrazil commented Mar 5, 2020

Martinnord commented Mar 6, 2020

lucastobrazil commented Mar 8, 2020

Steveeeie commented Mar 16, 2020

quantizor commented Mar 16, 2020 via email

tuck2002 commented Mar 30, 2020

Steveeeie commented Apr 1, 2020

Martinnord commented Apr 6, 2020

aulneau commented Apr 6, 2020

quantizor commented Apr 6, 2020

StevenLangbroek commented Apr 6, 2020

peduarte commented Apr 6, 2020

quantizor commented Apr 7, 2020

kachkaev commented Apr 7, 2020

stevesims commented Feb 7, 2020 •

edited by kitten

Loading

stevesims commented Feb 7, 2020 •

edited

Loading

diondiondion commented Feb 7, 2020 •

edited

Loading

penx commented Feb 7, 2020 •

edited

Loading

kitten Feb 13, 2020 •

edited

Loading

quantizor commented Mar 5, 2020 •

edited

Loading