New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Components: Implement Button as assigning ref via forwardRef #6527

Merged
merged 2 commits into from May 8, 2018

Conversation

Projects
None yet
4 participants
@aduth
Member

aduth commented May 1, 2018

This pull request seeks to bring in React's (new as of 16.3.0) forwardRef as an alternative solution for components which need to expose its internal DOM representation. A Button abstraction is a perfect use case for this, where we expose an instance function focus to recreate the native DOM behavior. Instead, we can simply forward the ref so that any parent component which assigns a ref to Button will have its value assigned as the actual DOM node.

Testing instructions:

Verify that there are no regressions in the behavior of button, particularly in the two places where its ref is used for focus: Permalinks returning focus after pressing "OK" on an edit, and similarly for Shared Blocks pressing "OK" on an edit, returning focus to the permalink and Edit buttons respectively.

@noisysocks

noisysocks approved these changes May 4, 2018 edited

Love this.

If memory serves me, PostPermalink was the only component using focus(). I tested editing post permalinks and there are no regressions.

👍 once Travis CI is happy.

// Disable reason: This test is desirable, but unsupported by Enzyme in
// the current version, as it depends on features new to React in 16.3.0.
//
// eslint-disable-next-line jest/no-disabled-tests

This comment has been minimized.

@noisysocks

noisysocks May 4, 2018

Member

Should we e.g. create an issue to remind us to unskip this in the future?

This comment has been minimized.

@aduth

aduth May 29, 2018

Member

Should we e.g. create an issue to remind us to unskip this in the future?

Created at #7005

@aduth

This comment has been minimized.

Member

aduth commented May 4, 2018

Hmm, unfortunately seems to be another instance of Enzyme lagging behind React: airbnb/enzyme#1604

Was able to implement the workaround for the buttons tests themselves, but will have to see what I can do for other components which render buttons (failing Autocomplete tests, for example).

@aduth

This comment has been minimized.

Member

aduth commented May 4, 2018

While not the most beautiful thing, I was able to work around the issue by adding a global mock for Button to effectively unwrap the forwardRef. I'll plan to create a task to revisit both this and the skipped test.

cc @Xyfi who I see encountered similar issues in #6261 with forwardRef.

@noisysocks noisysocks merged commit 0bdcdfa into master May 8, 2018

2 checks passed

codecov/project Absolute coverage decreased by -0.02% but relative coverage increased by +56.07% compared to 480990a
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@noisysocks noisysocks deleted the add/forward-ref branch May 8, 2018

@gziolo

This comment has been minimized.

Member

gziolo commented May 29, 2018

Hmm, unfortunately seems to be another instance of Enzyme lagging behind React: airbnb/enzyme#1604

yes, this is pretty sad that they failed to upgrade to React 16.3 :(

mount( <ButtonWithForwardedRef ref={ ref } /> );
expect( ref.current.nodeName ).toBe( 'button' );

This comment has been minimized.

@aduth

aduth Jun 18, 2018

Member

This test will fail when unskipped: Element#nodeName returns uppercase, so should be asserting as toBe( 'BUTTON' );

This comment has been minimized.

@gziolo

gziolo Jun 18, 2018

Member

It may take another few weeks until we can unskip those tests :(
The day when we remove Enzyme is becoming a reality if there is no progress on supporting React 16.3+

@mtias mtias added this to the 3.1 milestone Jun 20, 2018

@gziolo gziolo referenced this pull request Jul 25, 2018

Merged

Tests: Improve configuration and mocking strategy #8188

4 of 4 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment