Before react hooks, we called functional components to stateless components.
At that time it was really faster than class components but what about now?
Since we have react hooks, stateless components are no longer precise.
Does the functional components are faster than class components which runs same functions?
e.g.
In functional components,
I can handle state variables by using useState hook.
useEffect can represent componentDidMount, componentWillReceiveProps or some other lifecycle methods in Class component.
... ... ...
We have many other hook functions but which hooks will make my class components faster or lightweight?
Using React hooks will definitely reduce the amount of code you have to write in comparison to class based components.They are much easier to read and debug.
In sense of Performance , in class components :
Cleaning up and applying the effect after every render is task heavy,
and we might right run into issues or bugs.
so overall Hooks is a better option.
source
Both functional and class components in React offer the same functionality. You shouldn't miss anything when using any of the approaches and then you shouldn't differ in rendering performances.
In general, you write less code by using a functional component. This will be more understandable by your colleagues
According to the docs, there is no difference in terms of performance: https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-because-of-creating-functions-in-render
Related
Currently, I am using Redux and the mentioned hooks for react projects. However, useMemo and useCallback can quickly lead to bugs (tricky ones) very quickly in my opinion. As I understood, these hooks are required to avoid unnecessary re-rendering of components since react is checking referential equality.
I want to get rid of the above-mentioned hooks and let MobX handle all the reactive stuff. I wonder if I totally can get rid of them (useCallback, useMemo) and therefore everything updates automatically.
Does MobX come with slower performance?
Is it even possible to totally get rid of them with MobX?
Can UI components also only relay on MobX (e.g. setting loading boolean or boolean for toggle modal visibility)?
Also, I read useContext should not be used for high frequent updates. However, MobX is really often used with the hook (talking about mobx-react-lite). So is it even a good idea to use MobX for UI updates?
First of all you do not really need those hooks.
useMemo - is for laziness value, nothing will happen if you decide to ditch it and simply get your value.
useCallback - like useMemo for functions, again you can declare a function without wrapping it in useCallback function.
From React useMemo and useCallback
You may rely on useMemo as a performance optimization, not as a semantic guarantee.
useCallback(fn, deps) is equivalent to useMemo(() => fn, deps).
For 99% of the cases those hooks are use for optimizations, they are not related to MobX or Redux and you can simply not use them.
unless you have a very specific use case that other questions in StackOverflow are suggesting you to use them.
I personally hate redux, it sounds good at first but than you realize it is a big monster to continuously maintain.
MobX takes another approach to manage global state of your app that also sounds good at first but then you dive in and see the implementation with a tweak of useState to trigger forceRender and use some voodoo with observable wrapper function component.
That's why I have recently created a simple react state management package that in my opinion way too simple to understand maintain and scale(I use this pattern in several large apps)
It is called react-spear.
I would really appreciate to hear any thoughts of it, I think this approach makes global state management really easy.
Hooks, as I understand them, are just a way to add state (and lifecycle methods) to function components.
This FAQ answer:
In the longer term, we expect Hooks to be the primary way people write React components.
https://reactjs.org/docs/hooks-faq.html#should-i-use-hooks-classes-or-a-mix-of-both
and this documentation snippet:
Hooks let you split one component into smaller functions based on what pieces are related
https://reactjs.org/docs/hooks-intro.html
confuse me slightly as a React beginner.
It is as if I have to think about my app in terms of hooks rather than in terms of elements and components.
React didn't remove components, but the quote hints that hooks will replace
components as the primary source of code reuse.
Can one still talk about elements and components as primary abstractions in React?
The concept of components is not going away, it's just how they are written that is changing.
The second line you quoted
Hooks let you split one component into smaller functions based on what pieces are related
Is poorly worded in my opinion, and should rather say "Hooks let you split one class component into smaller functional components..."
So instead of having one monolithic class that handles all state and lifecycle logic in methods like componentDidMount, componentDidUpdate, you can split areas of concern and have smaller functional components that only care about things directly related to themselves.
Edit: This snippet from the hooks-intro doc might be helpful:
Hooks don’t replace your knowledge of React concepts. Instead, Hooks provide a more direct API to the React concepts you already know: props, state, context, refs, and lifecycle. As we will show later, Hooks also offer a new powerful way to combine them.
Currently, there are 2 ways of building components in React:
Class Component
Functional Component
You can check them here. The way you build it it's different. In case you approach the class component, that means that you need to work with the prototype of the object.
On the other side, if you choose to go as a functional component, that means that everything you request from React, is invoking a function, and not using the prototype at all. All this chaining from JS can slow down the performance, and that's why the React core team decided to go into pure functional direction: It can perform better, and it makes it even simpler to read it (once you get used to it).
Regarding the second quotation. It is a way to show more benefits of functional programming over classes. They are more flexible and can have a better composition for it.
One last addition: Approaching functional components doesn't mean you can ignore to learn class components. There's still a lot of apps with some legacy code. I would recommend learning both, and whenever you need to create new components, approach the functional component paradigm.
I'm not really facing an issue, it's more like I'm wondering what is the best way I should use mobx with react. So here's my situation:
I'am fairly new to mobx but I've got years of experience using react (mostly with redux).
My new project is using mobx-state-tree alongside with mobx-react-lite in order to connect my components with the function observer wrapping the component. I've set up a root store with multiples stores in it.
I'm really enthusiastic about it for now but I would like some recommendations:
Should I use the containers logic which is pretty common with redux, which means I should only connect a "container" component who will handle the connection with my stores and spread it to its children ? Or should I connect directly with an observer as many components which needs to be provided with data from a store ?
Is the second option more optimized, technically speaking ? Is it still a good idea according to React philosophy ? What's YOUR opinion on this subject ?
Any answer would be really appreciated
Technically, you don't need container/presentation concept. You can use context, or localStore, or globalStore but it doesn't mean container/presentation not useful sometimes.
Mobx patches shouldComponentUpdate lifecycle, and basically optimizes components rendering for you.
mobx-react mentioned in their docs that the more components connected with observer, the better.
It's very common pattern to see shouldComponentUpdate with a bulky checks to avoid unnecessary renders. This isn't needed with MobX at all.
My opinion is that patterns change on monthly basis, so learning the general concepts can ease your transition from global store, local store, context, hooks and other api changes.
React component patterns also change overtime.
Use what you need and understand right now. If it won't matter in 5 years, don't spend more than 5 minutes to think about it. You can always do a fun refactor.
Further reading:
https://mobx.js.org/README.html
https://mobx-react.js.org
I am curious whether there is any difference when we try to differentiate react components as controlled vs uncontrolled and stateful vs stateless. Are we differentiating the same thing here with different terminologies or is there an actual difference when we distinguish in such a way? I am beginning to suspect there are subtle changes but cannot wrap my head around them. If there are no differences please provide a brief explanation as to why such a reasoning is invalid. If there are please explain the differences no matter how minute they may be.
While in a few cases, these terminologies might mean the same, there is actually a difference between them
controlled vs uncontrolled is basically used to specify whether the view or the state of the component can be controlled from within itself or from outside.
stateless vs statefull is used to describe whether the component contains state or not. A controlled component can also contain a state. In React generally a stateless component is written as a Functional component which is View only component but can also be written as a Class component making use of lifecycle method/or not
I know using #observer on more small components is good for the performance. Is it also reasonable to use #inject on as many as possible components ? Obviously, in this way it is easier to access the used props than passing through parent components. At the same time, it also becomes difficult to create presentational components. Nearly all components are directly connected to Mobx's stores. But even if we don't use #inject, components may still use #observer.
So my questions are:
How to create presentational components in Mobx? Or maybe there is no need for presentational components in Mobx.
What is the best practice to use #inject ? Or which components are reasonable to used with #inject?
Any suggestions are appreciated.
Question1:
You create presentational components the same way as in redux. Just give these components the props from outside and only use #observer on them.
There is no "need" to use presentational components. Even in Redux there is no need. It just depends on how you can reach your architectural goals/non-functional requirements.
You need to know and decide if you need presentational components without #observer. That could be the case when you for example want to reuse the presentational components in an application, that doesn't use mobx. Then you will run into problems when you have annotated every component with #observer.
Question2:
Use #inject and #observer on the container components and just pass the props down to your presentational components that are only annotated with #observer.