Skip to content
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

Update the block component to use react hooks instead #14985

Merged
merged 5 commits into from May 7, 2019

Conversation

@youknowriad
Copy link
Contributor

commented Apr 15, 2019

I said previously that we're not going to refactor our components to use hooks just to use hooks. But in this PR, I'm trying to refactor the BlockListBlock component.

The main reasons are:

  • The component is one of the most complex one in the repository and using hooks clarifies its code as related behaviors/functions/state are grouped.
  • This is one of the bottleneck components in terms of performance, and I'd like to explore whether we can make improvements using hooks or not.
  • I have some plans to bring new features to this component and I don't want to just continue growing without some "organization".

At the moment, I kept the refactoring as minimal as I can, which means I kept, in theory, the same flows, states... There's something different though which can be impactful. A lot of the callbacks are not bound the instance object which means some child components might rerender more often. There are options and solutions but I want to measure the differences before making changes.

  • I can use useCallback to memoize these callbacks
  • I want to be mindful of the memory impact of memoizing all of these callbacks, maybe these are rerendered regardless of the callback change which means the memoization can be more costly than anticipated.
  • Another option could be to move some of these callbacks to the withDispatch HoC instead.
@mtias

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2019

This is a good start. Making this code more straightforward is going to help always keeping a cleaner state for any future iterations.

There's another motivation for making use of hooks here which is getting some more concrete awareness of how they can later benefit the consumable block API (exposing some of what has been so far absorbed in support or higher order components through hooks) and its tradeoffs.

@youknowriad youknowriad force-pushed the update/block-component-hooks branch from 8f72942 to f33e227 Apr 16, 2019

@youknowriad

This comment has been minimized.

Copy link
Contributor Author

commented Apr 16, 2019

I run the performance tests to compare this branch against master and noticed similar times. This refactor has no impact on performance.

Can I get a review here, I'm thinking of merging this as is and try other smaller improvements using hooks separately.

@youknowriad youknowriad force-pushed the update/block-component-hooks branch 2 times, most recently from 79f7a6e to 453dc59 Apr 16, 2019

@youknowriad youknowriad requested a review from WordPress/gutenberg-core Apr 17, 2019

@aduth

aduth approved these changes Apr 29, 2019

Copy link
Member

left a comment

It's a bit difficult to review, but it appears in good shape. I like how hooks help to consolidate where previously we have disjointedness of checking for changes in props values between componentDidMount, componentDidUpdate.

The issue with the ESLint warning should probably be resolved. There's also a merge conflict.

@youknowriad youknowriad force-pushed the update/block-component-hooks branch from 453dc59 to 9fd8640 May 7, 2019

@hypest

This comment has been minimized.

Copy link
Contributor

commented May 7, 2019

@Tug , can you give this PR a quick look to see if it can affect the native mobile in any way? cc @youknowriad

@youknowriad youknowriad force-pushed the update/block-component-hooks branch from 62ad155 to 709cf53 May 7, 2019

@Tug

This comment has been minimized.

Copy link
Contributor

commented May 7, 2019

@hypest afaics it's only touching BlockListBlock which we're not using at the moment.
It might affect the way we port BlockHolder to gutenberg but it should not break anything right now.

@youknowriad youknowriad merged commit b66bbcc into master May 7, 2019

1 check passed

Travis CI - Pull Request Build Passed
Details

@youknowriad youknowriad deleted the update/block-component-hooks branch May 7, 2019

@youknowriad youknowriad added this to the 5.7 (Gutenberg) milestone May 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.