45% Faster React Functional Components, Now
Philippe Lehoux

Great article, thank you. More of such articles.

I’m always surprised how many people just “follows the guidelines” and do not dig deeper to realise how things work. React is NOT a framework or programming language, React is a javascript library (with some transpilation). So using javascript is the best one can do (and learning javascript, not React with vague javascript understanding).

Bundling state with components is one (small) part of React’s design that was not good. Fortunately tools like recompose fix this and separates state and pure components. This is the way React should be. And articles like this one from Phillipe greatly help to understand React and demystify it.

Learning from the masters is great way to understand our tools. Again — this free video course about recompose is great and especially the last episode that describes the optimization mentioned in this article. Worth of reading the code and understanding. Especially the part where is cancel optimization when you add propTypes to functional component. Even FB realized that the PropTypes are just specialized typechecking and (will) put them out of React (in next version), because we have better tools (and maybe / hopefully they decided to optimize functional compoments finally). React Router 4 went from “complex solution” to much more flexible routing tools, too (but still a long way ahead).

Some commenters mention here that “something may break”. Without knowing what may break (because of not knowing the internals) it is ultimate argument to “follow what we are told to”. I learnt a lot from Dan Abramov redux (and enjoyed learning Elm thanks to it). He did not follow the “flux recommendation” and made much nicer, cleaner and usable solution. Unfortunately recently he advocates the “follow React” when discussing about Preact or Inferno. Having standardized (and fast and optimized) functional components (functions) is desirable but even here is space for improvement (eg. Marko). Lifecycle may be done with tool of choice. Vue lifecycle methods slightly differs from React and … why not? Still the basic ones are the same. That’s why I hope more such libraries to emerge, and even more I hope that they will find a new way how to do things, not just follow and be compatible with React.

I like React, I’m using it every day and I’m extremely grateful that it exists. I’d be even more happier to see people asking about how it works more (because we are curious programmers after all) on one side and see it to be more modularized (at least from the functional component and lifecycle methods side).

React rocks and javascript and fresh ideas even more.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.