React: Why remove shouldComponentUpdate property for functional components?

[nxstack]

Do you want to request a feature or report a bug?
feature
What is the current behavior?
shouldComponentUpdate for functional components feature is already implemented in fiber alpha release. But in comment it is written that it will be removed in final release.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/84v837e9/).

What is the expected behavior?
Allow optional shouldComponentUpdate property for functional component.
**Which versions of React, and which browser / OS are affected by this issue?
React v16

Did this work in previous versions of React?**
No

Today, I was planning to add shouldComponentUpdate property for functional component and open a issue on GitHub for adding shouldComponentUpdate and send a patch for it. But I saw shouldComponentUpdate is already implemented for functional components.

But there is comment written in code that
// TODO: Disable this before release, since it is not part of the public API
// I use this for testing to compare the relative overhead of classes.
if (typeof fn.shouldComponentUpdate === 'function' && !fn.shouldComponentUpdate(memoizedProps, nextProps)) {
}

I think this is very useful feature and should be part of the public API. We don't need to use class based Pure component. Any idea why this is not going to final release?

[Daniel15]

Why not just use an ES6 class if you need features that aren't available in stateless functional components?

[domenikasd]

Εχω προβλημα εβαλα αυτο τονλογισμικο γ να βλεπω τους κωδικους κ λεξεις αλλα δν ξερω πως να το χρησιμοποιησω .που να παω κ να δω τι .οραν δυνδεομαι .αλλα το λογισμικο το χω σε αλλη συσκευη βοηθεια

[nxstack]

Because,

1. Functional components doesn't need to be instantiated and are lightweight than class components and hence are potentially more performant than class components.

1. We write code for humans. When I write functional component, I am conveying to the reader of the code that I don't want to use any state inside my component. When I write class component, it doesn't convey that idea very well. If I created a class component then reader of the code may get a wrong message that may be in future class components might have state or other lifecycle methods.
   It's the same logic why we have functional components when class components can do everything a functional component.

Adding shouldComponentUpdate for functional components is not a costly operation. It's just about putting single check and there is no need to worry about instance and other complexity.

In a significant size functional component sub-tree, this benefit of shouldComponentUpdate can potentially save some CPU cycles and people can measure and use shouldComponentUpdate if they need to. But the code still remains the same. Refactoring functional components to class components is probably not a great idea in my opinion.

[nxstack]

I think fiber release is a great opportunity to add shouldComponentUpdate for functional components and let the users decide if they want to use it or not. Unless there is some other reason, that I don't know about, it is not clear to me. We already use defaultProps property in functional components, why not add just another one shouldComponentUpdate? I am sure several people have requested for this feature in the past. Recommending users to use class components instead(which could potentially make component less efficient than before), is not the right way to solve this problem in my opinion.

If there is any other specific reason why React doesn't want to do it then probably it makes sense not to do it. But if there is no reason, then why not provide this flexibility? I know several people don't want to use class components if there is no state. Then why force them to use class components for shouldComponentUpdate?

[gaearon]

We might do it—there is no decision on this yet.

why not add just another one shouldComponentUpdate?

Because we plan to have a full fledged API for stateful functional components in the future, and it may be implemented in a different way (e.g. component could be an object with "static" methods). So we avoid introducing APIs that we might scrap in the future in favor of a more complete solution.

I understand it's not ideal, but we're just not sure this is a good API long term, and we'd rather avoid churn than expose too much sugar now and have to change it later.

[nxstack]

That makes sense.

There is just one more thing, even if you are planning to add support for stateful functional components. Functional components will still exist. This means that users who have already return large codebase using functional components might have to refactor them to stateful functional components to be able to use benefits of shouldComponentUpdate. I think simple functions should remain simple(unless someone wants performance benefits sometimes and it doesn't have any harms).
I don't see any harm with adding shouldComponentUpdate, because there is no performance cost(except single check), API will be 100% backward compatible and you get to choose if you want to use it or not.
But yeah I agree that this solution should work for the long term.

I just wanted to express my concern and wanted to understand reasoning behind not adding shouldComponentUpdate. I am sure you guys will come up with the best possible solution for this.

Thanks.

[gaearon]

Yea, we totally understand the desire for this.

I think that when we approach stateful functional component API, we'll make feel like a natural progression over stateless functional components, instead of something completely different.

[gaearon]

I'll close for now as this is part of bigger API changes that we aren't ready to do.

[rnemec]

Is there a place we can vote for this?

[gaearon]

We don't design APIs based on a number of votes 😉 That would not produce a very good design.

We're very well aware of this feature request. But it needs to be considered as part of a larger component API redesign. We will likely start thinking about this again in 2018. We'll share our ideas when we think we have something that might be a viable direction.

[rnemec]

Thanks, Dan. Sorry for letting my impatience seep through 😄

[StephenHaney]

Good reasoning on not introducing temporary API... in the meantime, what's the best way to make a pure SFC? Create a PureComponent class that wraps the SFC? Is there any point to the SFC if we're just wrapping it in a class style component?

[mikew]

One thing I'm noticing is that the newer React APIs don't play well with class-based components.

React.forwardRef needs to be passed a function and a HOC must be used to workaround. Granted this doesn't affect application code that much, more library based stuff.

React.createContext can't be use in class-based lifecycle methods, unless you create a yet another HOC to workaround.

Until SFCs can be treated as pure, I'm wary of using them.