3 ms·
Why would you do that? What’s wrong with this? useEffect(() => { const interval = setInterval(myFunc, 1000) return () => clearInterval(myInterv
by erikpukinskis 5y ago
Why would you do that? What’s wrong with this?
useEffect(() => {
const interval = setInterval(myFunc, 1000)
return () => clearInterval(myInterval)
},[])
I think one of the keys to React is not to fear the boilerplate.
If you find yourself typing the same code too often, there’s probably a higher level abstraction that you should find, way above the level of setInterval.
I find coders often try to DRY up low level code to the detriment of actually dealing with their _application_ architecture.
In general, you should use the tools as provided, boilerplate and all, and then focus your real brain energies on the specific domain problems that only your application needs.
Creating thin wrappers on external tools to squeeze the last tiny bits of DRYness is not only usually a waste of time, but it makes your code unreadable. People know how setInterval and useEffect work. If I see useInterval I have to go read your code to know what’s happening. Especially if you made it configurable. And people _will_ tend to add configuration to these wrappers over time as needs change.
- lunfard00 5y agoin my experience is better to have customs hooks like useTimeout (react-use library is awesome) so is easier to test. Mocking hooks feels nice, mocking the browser API not so much...