Class Component
Before React Hooks, when we want to create a dynamic component, we have to create a class component and use lifecycle me...
For further actions, you may consider blocking this person and/or reporting abuse
Function based components are harder to read in my opinion and large codebases tend to look like spaghetti when using function components. For less complex stuff, they seem to be a good way to go, for more complex things or larger codebases I rather stick to well structured class based components.
I was also thinking that but then I read this overreacted.io/how-are-function-co... and it changed my view about functional components , they seems more reliable than class components.
agreed
New to React (I've only read about it) so I may be wrong (and if I am, I'd like to know why) but I don't think you need the changeTime function in your hooks example, you can call setTime directly which would reduce it even further. Is it just a question of code style?
useEffect(() => {
const tick = setInterval(() => {
setTime(new Date())
}, 1000)
return () => clearInterval(tick)
})
It's good practice to decouple your code
If setTime() is added to useEffect() then it'll have to be added as a dependence also. This could trigger useEffect many times if setTime() is used else where and create an endless loop.
I think you left out the listener filter (empty for setup and tear down ... otherwise this gets called on every update to any state.
The useEffect call in your example is missing an empty dependency list. This probably isn't quite doing what you think: it's setting up a new timeout every time the component re-renders.
Ironically, a class component almost certainly wouldn't have such a problem because of the clearly named
componentWillMountmethod.That said, helpful article and I am generally a fan of function components.
I prefer to use class components, but it's personal preference more than anything. Class components and function components (with hooks) both have pros and cons.
One of the problems with class components is dealing with callback scope, i.e. what "this" references, but that can be handled easily these days by attaching a simple decorator to the callback methods. This isn't an issue for function components.
One of the problems with function components (with hooks) is every time the component is rendered, nearly every function in the component (either top-level or passed into a hook) has to be recreated, and that will cascade down through the hooks you use. That can end up being quite painful for performance and/or the garbage collector. This isn't an issue for class components.
You can do almost everything with class components as you can with function components, and vise-versa, so which one people decide to use is personal preference and/or an architectural design decision. I don't believe one is significantly worse than the other.
Hey Danielle! Had a quick question for you. Now that hooks have brought state to functional components, beside concision why would someone use a class component over a functional component?
Hi Tian,
In my understanding, class components can be replaced by functional components with hooks. But for some old projects, they are still using class instead of rewriting the whole project.
Also as react team said, they won't stop supporting for class but they suggest trying hooks on new projects. Check this on react docs 👉🏻: reactjs.org/docs/hooks-intro.html#...
Nice and clear article.Thanks a lot for sharing :)
Why would someone use class-based components over functional components right now?
Why does the useEfrect return the clear interval function? How does it work??
How can we pass state properties between two functional components?
Im also new to react, so take it with a grain of salt:
You create a custom Hook in a separate file, which you can import then, this is your childComponent, as long as you follow the naming Schema (use*), state props should propagate automatically
It seems that in the hooks example you didn't clear the interval. Why is that?
Hey Raul, thanks! You are right and it is a good point! I updated the code. It is a valid concern when the app is not server-side rendered.
Danielle this is an awesome post. Keep it up!