search

WordPress / developer-blog-content

In this GitHub space, WordPress team coordinate content to be published on the Developer Blog. Discussion and montly meetings (first Thu) in WP Slack #core-dev-blog
36 stars 2 forks source link

React best practices and pitfalls #217

Open bph opened 5 months ago

bph commented 5 months ago

Discussed in https://github.com/WordPress/developer-blog-content/discussions/205

Originally posted by **gaambo** January 12, 2024 I think a lot of WordPress developers are pretty familiar with PHPs pitfalls and things that can impact performance. Also PHP is kind of "easy" to debug being server-side (eg with xdebug). But this knowledge often cannot be transferred to react since it runs on the client and completely different things impact performance in react (eg hooks, things causing too many re-renders etc). I think these things become more important with more and more UI being migrated to react. When a lot of plugins provide components, subscribe to redux store actions etc the browser has to handle more and more workload. And we should do our best to optimize that code. The idea came to me, when I saw that Gutenberg v17.4.0 contained some bug fixes for moving useSelect calls (eg https://github.com/WordPress/gutenberg/pull/57240, https://github.com/WordPress/gutenberg/pull/57358, https://github.com/WordPress/gutenberg/pull/57077, https://github.com/WordPress/gutenberg/pull/57032) React performance best practices are a difficult topic and probably not one that can be explained in one single blog post. But the post could still be a starting point for some things and then maybe link to the react documentation. Some ideas: - the rules of hooks - how do hooks work - how do hooks impact re-renders - how do contexts impact re-renders - how do props impact re-renders of children (eg blocks have a lot of props and they change very frequently during editing) - disadvantages of using/nesting many higher-order-components - impact of SlotFills - testing performance with react developer tools (see reasons for re-renders, measure,...) - impact of filters (addAction, addFilter) - impact of redux store subscriptions (eg to get the post type, but those subscriptions get called on every store change) Maybe a part of the project could also be to revisit existing examples in the block development documentation and open issues to fix those as well. I'm not a react pro myself, and struggle with these topics as well. So I think this post could best be written by a real react developer. But I would be happy to help and learn things on the way as well. I think related topics could be #184 #78
bph commented 5 months ago

@gaambo thank you for submitting the topic. It as approved at today's Editorial Group meeting.

Would you please comment on this issue so it can be assigned to you as the writer. (GitHub is quirky that way)

bph commented 5 months ago

If you haven't seen those pages yet.:

gaambo commented 4 months ago

Just wanted to add, those are some of the commits I find interesting: https://github.com/WordPress/gutenberg/pull/56783 - maybe this is something that's interesting for extenders hooking into BlockEdit filter? https://github.com/WordPress/gutenberg/pull/56847/ https://github.com/WordPress/gutenberg/pull/56957 https://github.com/WordPress/gutenberg/pull/56915

It seems @ellatrix made a lot of commits for improved performance with store subscriptions/selectors. So maybe she can give some input :)

ellatrix commented 4 months ago

It boils down to: adding block editor store subscriptions should be avoided inside blocks. If necessary, try adding it only for the selected block. You can early return in the useSelect callback.