Is functional componet more faster than class component in react? - javascript

I have read in a few places to check this problem, but didnot find any good answer.
I hope good answer to it.

There is not any noticable performance difference in functional and class components. It is completely dependant on developer's preference what one likes. Just the things to note is,
you can reduce the number of lines in a functional component as compared to class component.
There is also fewer limitations in functional components as compared to class components
You can handle many lifecycle of the component just inside useEffect.
These all point in turn reduce the time of development.
You can refer to this article for more indept details: https://betterprogramming.pub/react-class-vs-functional-components-2327c7324bdd
There is also a benchmarking done in this article. https://jsfiddle.net/69z2wepo/136096/
Here are the findings:
You can notice here that, functional components take less time than class components, but not much significant.

I think no.
It's unlikely to see any performance difference from classes vs functions.
However the way we optimize classes and functions are different.

Related

How many props is recommended in a React component?

Do you have any recommendations on how many props should be the best in a React component? I know there's no strict rules about the number of props, I'm looking for advice from experience developers to make the code clean and easy to read (I mean "best" is that).
I feel the number of props is similar to the number of parameters in other languages. In PHP, some people recommends to have <= 5 parameters. What about React?
And related to the number of props, do you have any methods to reduce it?
Thanks
Note that this is only aesthetics issue, you can send as many parameters as you like, but there are best practices.
As you said, it's just like parameters to a function. Well, props are parameters.
I would suggest using the minimum possible as long as it's readable.
Sometimes having 2 parameters (props) might even be confusing, say you send age and systemConfig to a component, these props are not related and might confuse the developer that will look at it in the future (This will probably be you)
And sometimes, having 7 props is ok because it's readable and all in the same domain. for example: you might send many person properties like age, height, weight etc. and it'll be fully readable.
Also, you might say, ok what if I'll send 50 parameters for that person component, in this situation you might be better sending the Person object as it is and let the component "dig" into the object and take all the variables that it requires.
In fact, the number of props have very little connection with best practice and clean code. For example, an ant design component has over 9 props, and this is not mean ant design doesn't have clean code, best practice,..etc. if you implement a generic component with child components in order to use available places in your application, you would have to pass most of the props that child components have and it will most probably have 5+ parameters.
Consequently, the important thing is that you should have a general way of code, a mind. If there is a way of thought behind the implementation and if it is clean and understandable; counts will be nothing for other (good) code reviewers.
I follow this rule of thumb: Three props is fine. Five props is a code smell. More than seven props is a disaster.
Of course this is not universal solution but my advice is that you must keep your component clear and easy to maintain. If the number of props are making the component bloated then you have reached your limit.
Proper composition should help you avoid passing props through multiple components. Try to handle events at the lowest possible point in the component tree.
Also to keep in mind if the component itself has a lot ot props then either:
Your components are each doing too much, and/or
Your components know too much about, and manage too much for, their children.

When to use a class component and when to use a functional component

I'm new to react.When I go for an interview they ask me When to use a class component and when to use a functional component ?.I do not know the answer to this question.I know the difference between the two.How best to answer this question?
In current post-hooks era the answer is simple: you always use function components.
Simply explain the difference. You said you know what the difference is, so tell them what it is.
Use class components when you need to keep component-level state or use lifecycle components. Functional components can now use state and some lifecycle methods with hooks though, so it's up to personal preference.
Functional components are considered easier to read and are less code than classes. They should be used in presentational components (small components dealing with how things look, not how things work).

When should I use React hooks? [duplicate]

With the introduction of hooks in React, the main confusion now is when to use function components with hooks and class components because with the help of hooks one can get state and partial lifecycle hooks even in function components. So, I have the following questions
What is the real advantages of hooks?
When to use function components with hooks vs Class components?
For example, function components with hooks can't help in perf as class components does. They can't skip re-renders as they don't have shouldComponentUpdate implemented. Is there anymore reasons?
The idea behind introducing Hooks and other features like React.memo and React.lazy is to help reduce the code that one has to write and also aggregate similar actions together.
The docs mention few really good reason to make use of Hooks instead of classes
It’s hard to reuse stateful logic between components Generally when you use HOC or renderProps you have to restructure your App with multiple hierarchies when you try to see it in DevTools, Hooks avoid such scenarios and help in clearer code
Complex components become hard to understand Often with classes Mutually unrelated code often ends up together or related code tends to be split apart, it becomes more and more difficult to maintain. An example of such a case is event listeners, where you add listeners in componentDidMount and remove them in componentWillUnmount . Hooks let you combine these two
Classes confuse both people and machines With classes you need to understand binding and the context in which functions are called, which often becomes confusion.
function components with hooks can't help in perf as class
components does. They can't skip re-renders as they don't have
shouldComponentUpdate implemented.
Function component can be memoized in a similar way as React.PureComponent with Classes by making use of React.memo and you can pass in a comparator function as the second argument to React.memo that lets you implement a custom comparator
The idea is to be able write the code that you can write using React class component using function component with the help of Hooks and other utilities. Hooks can cover all use cases for classes while providing more flexibility in extracting, testing, and reusing code.
Since hooks is not yet fully shipped, its advised to not use hooks for critical components and start with relatively small component, and yes you can completely replace classes with function components
However one reason that you should still go for Class components over the function components with hooks until Suspense is out for data fetching. Data fetching with useEffect hooks isn't as intuitive as it is with lifecycle methods.
Also #DanAbramov in one of his tweets mentioned that hooks are designed to work with Suspense and until suspense is out it's better to use Class
Hooks greatly reduce the amount of code you need to write and increase its readability.
It is worth noting though that there are hidden processes going on behind (Just like component did mount etc.) that mean if you don't understand what is going on it can be difficult to troubleshoot. It is best to experiment with them and read through the docs fully before implementing on a live project.
Also there is still limited support/documentation for testing hooks compared to classes.
https://dev.to/theactualgivens/testing-react-hook-state-changes-2oga
Update 28/08/2020
Use the react hooks testing library with custom hooks for testing
https://github.com/testing-library/react-hooks-testing-library
Officially it sounds like hooks will completely replace classes?? maybe one day, but think about it; hooks have been around for 3 years (as of Mar 2021), and there are pros and cons in adopting them (More pros than cons... don't get me wrong)
I have plenty more experience myself with state management/classes and after doing a lot of research and testing, I found out that we need to know both classes and hooks very well. Hooks require a fraction of the code for simple components and seem excellent for optimizing HOCs. Meanwhile classes seem better with routing, container components and asynchronous programming for example.
I'm sure there are plenty more cases where each technology is better, but my point is that programmers need know both hooks and classes very well specially when working on projects with 100,000+ lines of code and millions of users. Read more here: https://stackoverflow.com/a/60134353/11239755

React Function Components with hooks vs Class Components

With the introduction of hooks in React, the main confusion now is when to use function components with hooks and class components because with the help of hooks one can get state and partial lifecycle hooks even in function components. So, I have the following questions
What is the real advantages of hooks?
When to use function components with hooks vs Class components?
For example, function components with hooks can't help in perf as class components does. They can't skip re-renders as they don't have shouldComponentUpdate implemented. Is there anymore reasons?
The idea behind introducing Hooks and other features like React.memo and React.lazy is to help reduce the code that one has to write and also aggregate similar actions together.
The docs mention few really good reason to make use of Hooks instead of classes
It’s hard to reuse stateful logic between components Generally when you use HOC or renderProps you have to restructure your App with multiple hierarchies when you try to see it in DevTools, Hooks avoid such scenarios and help in clearer code
Complex components become hard to understand Often with classes Mutually unrelated code often ends up together or related code tends to be split apart, it becomes more and more difficult to maintain. An example of such a case is event listeners, where you add listeners in componentDidMount and remove them in componentWillUnmount . Hooks let you combine these two
Classes confuse both people and machines With classes you need to understand binding and the context in which functions are called, which often becomes confusion.
function components with hooks can't help in perf as class
components does. They can't skip re-renders as they don't have
shouldComponentUpdate implemented.
Function component can be memoized in a similar way as React.PureComponent with Classes by making use of React.memo and you can pass in a comparator function as the second argument to React.memo that lets you implement a custom comparator
The idea is to be able write the code that you can write using React class component using function component with the help of Hooks and other utilities. Hooks can cover all use cases for classes while providing more flexibility in extracting, testing, and reusing code.
Since hooks is not yet fully shipped, its advised to not use hooks for critical components and start with relatively small component, and yes you can completely replace classes with function components
However one reason that you should still go for Class components over the function components with hooks until Suspense is out for data fetching. Data fetching with useEffect hooks isn't as intuitive as it is with lifecycle methods.
Also #DanAbramov in one of his tweets mentioned that hooks are designed to work with Suspense and until suspense is out it's better to use Class
Hooks greatly reduce the amount of code you need to write and increase its readability.
It is worth noting though that there are hidden processes going on behind (Just like component did mount etc.) that mean if you don't understand what is going on it can be difficult to troubleshoot. It is best to experiment with them and read through the docs fully before implementing on a live project.
Also there is still limited support/documentation for testing hooks compared to classes.
https://dev.to/theactualgivens/testing-react-hook-state-changes-2oga
Update 28/08/2020
Use the react hooks testing library with custom hooks for testing
https://github.com/testing-library/react-hooks-testing-library
Officially it sounds like hooks will completely replace classes?? maybe one day, but think about it; hooks have been around for 3 years (as of Mar 2021), and there are pros and cons in adopting them (More pros than cons... don't get me wrong)
I have plenty more experience myself with state management/classes and after doing a lot of research and testing, I found out that we need to know both classes and hooks very well. Hooks require a fraction of the code for simple components and seem excellent for optimizing HOCs. Meanwhile classes seem better with routing, container components and asynchronous programming for example.
I'm sure there are plenty more cases where each technology is better, but my point is that programmers need know both hooks and classes very well specially when working on projects with 100,000+ lines of code and millions of users. Read more here: https://stackoverflow.com/a/60134353/11239755

React App without state and props

I would like to know if it's fully consistent with the React principles.I made a React App without state and props.I've put pure javascript only inside componentDidMount e.g.
componentDidMount(){
const first = document.getElementById('first');
const second = document.getElementById('second');
function funk(){
console.log(first.innerHTML);
second.innerHTML = "Arrr";
}
funk();
}
Of course it's just an example, my app is far more complex.
Technically speaking, You can (as you may already know).
Should you do it? A big and glowing NO!.
With this approach of targeting the DOM directly, you are bypassing and missing most of the goodness that react has to offer with the Reconciliation and The Diffing Algorithm.
If you really (really) need to target the DOM, you can use react's ref API.
And you can see in their docs it's should be used sparingly :
Don’t Overuse Refs
Your first inclination may be to use refs to “make
things happen” in your app. If this is the case, take a moment and
think more critically about where state should be owned in the
component hierarchy. Often, it becomes clear that the proper place to
“own” that state is at a higher level in the hierarchy. See the
Lifting State Up guide for examples of this.
Yes and no
Yes, you can use it in some cases for utilizing complex jQuery plugins integrating react as a part of your project and so on...
I know that there are lots of haters of such approach but we should also understand business if it's possible to achieve a goal without spending 40-80hrs for coding it yourself - go for it.
No, you should not do any DOM manipulation in component live cycle methods unless you are very good with react and completely understand how things work internally in this library.
Changing DOM in such way will most likely cause performance issues because your components will not be able to utilize shadow DOM, as a result, your components will perform DOM manipulation after every change and could potentially slow down the application.

Categories