Every React Component in this Project is a Funtional Component killing Extensibility

[surapuramakhil]

This is how react components are written in this project.

const Index = () => {
.....
}
export default React.memo(Index);

If I want to make few components having custom changes to existing components which only makes sense to my site but not at Apache answer level. I won't be able to extend them since they are written as functional components. If OOPS can be applied there, then I would be able to make my changes.

[surapuramakhil]

@fenbox @PrimmaAnna @shuashuai request for your inputs

[shuashuai]

First of all, I think you should understand why the hooks feature was introduced in react 16.8 version.then compare the actual performance gap between FC and Component.

Why answer uses functional components

the most direct purpose is to enable rapid iteration and development, at the same time, during the development process, the smallest reusable components will be continuously extracted to improve the reusability and composability of components.

Then for those contributors who are not familiar with react, they do not need to consider the life cycle of the component, they only need to focus on the implementation of the business itself.

Regarding the scalability you mentioned, it is true that functional business components are not as scalable as OOPS, but from the perspective of use and rapid reuse, sacrificing some scalability in the process of fast reading iteration and development is worth it. and for some users who need to expand, if they only expand the UI, there is not much difference in the workload between the two. If both the UI and functions need to be expanded, I believe that from the perspective of code volume and code reading, The workload of the two should be about the same(from my personal experience).

[surapuramakhil]

But what about extensibility? You can't extend a functional component (it doesn't make any sense). If it's a component, I can rewrite the render method using the abstraction (methods / class variables) the base class provides. I can avoid a lot of duplicate code.

[surapuramakhil]

the most direct purpose is to enable rapid iteration and development, at the same time, during the development process, the smallest reusable components will be continuously extracted to improve the reusability and composability of components.

Does MR's creating smaller and smaller FCs are honored? It would result in too many components and tiny functions. And in most of the cases I need to reuse the functions which are defined inside FC. And those functions might not be standalone in some cases.

[shuashuai]

Does MR's creating smaller and smaller FCs are honored? It would result in too many components and tiny functions. And in most of the cases I need to reuse the functions which are defined inside FC. And those functions might not be standalone in some cases.

the finer the granularity, the more single the function can be ensured; as for the specific granularity to be split, it is determined by the simplest reuse principle within the project; so how to split your components depends on your actual business, and no one knows There is no guarantee that your current one is the best, I can only say that it is the most suitable.

[surapuramakhil]

The problem is that the entire code of the component is part of function definition and those are like temporary variables, killing extensibility. This also cause performance issues too - each time function get called, those variables need to be created.

[shuashuai]

Here are some considerations regarding function component performance:

1. creation and destruction overhead: Compared with class components, the creation and destruction overhead of function components is usually smaller. Functional components do not require instantiation, constructors and life cycle methods, so there is less performance overhead during the mounting and unmounting process.
2. repeated creation of functions and variables: Since the function component re-executes the function body every time it is rendered, functions and variables will be repeatedly created. This may cause some performance concerns, especially if the component renders frequently. However, modern JavaScript engines often perform optimizations when handling this situation, such as minimizing memory overhead through mechanisms such as garbage collection.
3. optimization techniques: By using techniques such as virtual DOM and reconciliation algorithms, React can be optimized during the rendering process to reduce unnecessary re-rendering. React also provides some performance optimization tools and techniques, such as using React.memo to memoize components, using useCallback and useMemo to cache functions and values, etc., which can help reduce unnecessary re-creation of function components.

In general, for most application scenarios, the performance impact of functional components is negligible. if there are indeed frequently used component internal functions that affect performance, then we can make specific optimizations for this situation.

[surapuramakhil]

creation and destruction overhead

It's a big statement, can you provide some concrete evidences for it. I don't think that's the case and never will be, as both are equivalent. React functional element is a simple object with 2 properties: type (string) and props (object). They are to provide convince to developer for developing / maintaining scalable frontend.

Here is my support link: https://flatlogic.com/blog/functional-components-vs-class-components-in-react-js/

In our case, using OOPS helps in extensibility. In not a fan of OOPS nor functional. I use both based on needs / requirements.

[shuashuai]

there really isn't enough data to tell the difference between the two,most people think that the overhead of creating inherited instances of class components is negligible, but I found an article about the advantages of function components. you can refer to it.
I'm sorry that the point I made above was not rigorous.

Here is the article: https://www.dhiwise.com/post/react-functional-components-vs-class-components

I think the simplicity of functional components is a very big advantage. At the same time, since hooks cannot be used in class components, unifying them all into functional components will not cause additional trouble.

[surapuramakhil]

I think the simplicity of functional components is a very big advantage.

💯 . I definitely agree with you; there is no doubt about the simplicity and benefits that functional components provide. Here are the changes required in a functional component to make them extensible.

1. Moving state out FC and FCs have to useState() of React (i.e. webhooks) for fetching state rather than generating it. (this is not the case in most of the FC components of this project). State creation logic has to be separated out from FC.

This still doesn't solve the problem of importing state to a derived component.
I am not expert in react. I feel react still needs to evolve for making FC extensible. I don't think they will be solving this problem

2. Moving methods which generate state out of FC. (there are a lot of methods which are written in each FC) which are not exposed and unable to reuse today.

These are two benefits which I get from inheritance of class. i.e. state and methods in FC.

In simple words, FC should only have view/presentation logic, Everything else has to be moved out.
Sorry I am not sure. How well this solution would work

[surapuramakhil]

#829

[robinv8]

When discussing scalability, it's important to identify scenarios and components that are suitable for scaling. It's not that functional components aren't suitable for extensibility. In fact, React Hooks provide a great way to achieve scalability through a more granular approach. By decoupling state and side-effect logic into independent Hooks, component code can be organized more efficiently, improving readability.

For example, consider siteInfoStore mentioned in issue #829. It is a Hook similar to Redux. If implemented as a class component, the code size will typically be larger than a function component. However, by using Hooks, the code can be more concise and maintainable.

So which scenarios are suitable for class components:

1. Need to use life cycle methods
2. Need to use instance methods
3. Compatibility with third-party libraries or legacy code

[robinv8]

I understand what you mean, but the current answers don't support dynamically inserting content into the footer. Currently, both class and function components can only be modified in code. Without changing existing components, you can also extend them in the following ways:

1. Add the children attribute to the Footer component
2. Use cloneElement
3. Directly manipulate the DOM

If you have a better solution, please share it.

[surapuramakhil]

Adding children attribute is nothing but modifying the component instead of extending it.

In OOPS, classes do support inheritance. For the above case, I write my custom Footer extending answer Footer. My custom class will rely on code of answer footer. I will need to rewrite render method, but most it would be using base class code. If the base class gets updated, then those changes get reflected too.

[robinv8]

You can edit #829 and let us see your solution, thanks.

[surapuramakhil]

Okay, I will add a demo of a customer footer.

[surapuramakhil]

@robinv8 react webhooks is blocker. So this approach is not possible. These are run-time errors.

[surapuramakhil]

Conclusion

Answer fronted i.e. React web App has very strong coupling with webhooks which make it hard to move away from FCs.

Now taking About Extensibility in Functional Programming
it's a foolish thing, it's more like applying OOPS concepts to Functional Programming. Functional Programming achieved via composition.
The only way is to rewrite the component. Of course, function programming composition would help you in rewriting.

@robinv8 @shuashuai request your inputs on conclusion. I will update this based on feedback

[robinv8]

There is a saying that existence is reasonable.

Nowadays, function components are obviously more popular than class components in the react community. Although function components also have some complaints, such as useEffect, they are very convenient to use. All front-end projects in our team are implemented based on React. Encountered a problem that the FC function cannot solve.

You are more than welcome to submit your ideas as a PR and we will discuss it.