Implement shouldForwardProp for React Native/Primitives

[macintoshhelper]

Tested with react-figma (with styled-components/primitives). Should work with React Native, but would be great if someone could test it before merging 🙂.

I had to do npm i -D bundlesize jest in the package folder. Should I commit the package.json with them as local dependencies? I try to avoid global dependencies where possible (to avoid version mismatches between packages, and make sure people have up-to-date versions).

fixes #3093

[macintoshhelper]

I copied this test over from the web entrypoint tests, but it fails, not sure if it's because of the use of findByProps, or test renderer doesn't work for children in React Native? Bit strange, should be fine to leave it out though

    it('should inherit shouldForwardProp for wrapped styled components', () => {
      const View1 = styled.View.withConfig({
        shouldForwardProp: prop => prop !== 'color'
      })`
        background-color: ${({ color }) => color};
      `;
      const View2 = styled(View1)``;
      const wrapper = TestRenderer.create(
        <Fragment>
          <View1 color="red" id="test-1" />
          <View2 color="green" id="test-2" />
        </Fragment>
      );
      const view1 = wrapper.root.findByProps({ id: 'test-1' });
      const view2 = wrapper.root.findByProps({ id: 'test-2' });

      console.dir(view1.props);
      expect(view1.props.style).toEqual([{ color: 'red' }]);
      expect(view2.props.style).toEqual([{ color: 'green' }]);
      expect(wrapper.toJSON()).toMatchSnapshot();
    });

[quantizor]

@macintoshhelper if you use yarn it should all work as expected because we use yarn "workspaces"

[quantizor]

So for native since there's no "default" prop whitelist to speak of, the default validator fn can just be a function that returns true.

[macintoshhelper]

Does a3569b2 address this? Updated the comments slightly too.

[quantizor]

I think this might have been a mistake?

[macintoshhelper]

There were two PRs for the useTheme export, a previous one by jladuval exporting useTheme from the native entrypoint, but I created one recently exporting useTheme in the primitives entrypoint, but had referenced the original native PR in the changelog.

Someone added a thanks note in the CHANGELOG.md which is in master now, referencing the author of the native PR, because I had linked to the wrong PR. Was correcting the PR reference here to the one that I opened for primitives, since the native one has already been published and is already in the CHANGELOG.md for an earlier release.

I hope that makes sense 😄.

[quantizor]

Oh ok, can you fix the link text to match the PR that was linked? (it says 2982 instead of 3108)

[macintoshhelper]

2982 has already been released and is in the CHANGELOG.md already, it should've been linked to here: https://github.com/styled-components/styled-components/blob/88ec191fdef0e0a07b40190170d60b01dee261a1/CHANGELOG.md#v501---2020-02-04

3108 is the correct PR for adding useTheme to the react-primitives entrypoint.

I had linked to 2982 originally here: https://github.com/styled-components/styled-components/pull/3108/files#diff-4ac32a78649ca5bdd8e0ba38b7006a1eR9 – but should be 3108 I think?

[macintoshhelper]

Are you asking me to revert it back to Added ``useTheme`` hook to named exports for react-primitives entrypoint (see [#2982](https://github.com/styled-components/styled-components/pull/2982)) thanks @jladuval!?

I can do so, but 2982 is for the native PR though. 3108 is for my react-primitives entrypoint PR, which this changelog entry is referring to.

This is the commit where the wrong thanks note (for native, not primitives) was added: 01e5747#diff-4ac32a78649ca5bdd8e0ba38b7006a1eL9

Sorry for the confusion! I'm a bit new to changelogs. Maybe worth creating a new issue/docs for changelogs to avoid confusion in the future around merge conflicts, PR references, etc?

[quantizor]

LGTM other than the one changelog nit

[quantizor]

Thanks for your work on this!

[macintoshhelper]

Np. Thanks for merging 🙂. Should I open an issue for discussing changelog merge conflicts? Maybe worth documenting a process in CHANGELOG.md for submitting PRs first, then submitting a new commit with a link in the changelog to the newly opened PR to help people avoid confusion in the future?