DEV Community: anil kumar chaudhary

useEffectX: A better alternative to useEffect

anil kumar chaudhary — Sat, 15 Aug 2020 17:01:01 +0000

My experience with React hooks have been amazing. In this article, I will precisely talk on one of the most prominent hooks that we use on a daily basis which is useEffect.

I am assuming the readers coming to this article has good understanding on useEffect. If not, please first go through the concept at reactjs.org.

So essentially, useEffect react to changes in dependency list. They have replaced componentDidMount, componentDidUpdate, componentWillUnmount and componentWillReceiveProps in class based react components.

It’s very common to react to changes in props values or state values over the lifetime of a component. we also need to compare previous values and current values when reacting to changes often. In the class based component, we had componentDidUpdate for the similar use-cases.

It has following interface:

componentDidUpdate(prevProps, prevState, snapshot)

You have access to prevProps(previous props) and prevState(previous state), which can be used to make comparisons and react appropriately.

What about useEffect, how would you do those kind of comparison with them?

Solution 1

You can have a usePrevious custom hook which will always give you the previous value and that you make use in your useEffect to complete the comparison. Let’s see some code.

Notice, how usePrevious hook helps us by keeping a track of previous value. Now think about scenario, when there are more than one dependency in our useEffect. We need to make use of usePrevious hook that many times or we have to re-define our usePrevious hook to track an array of dependency.

Isn’t it too much of work every time ?

Can we have something similar to componentDidUpdate ? We can have previous and current values of the dependencies as the argument of the callback of useEffect.

That could save us a lot of time while working with update scenarios in useEffect hook.

Solution 2

I was able to package everything in a npm package, which can act as a drop in replacement for useEffect anywhere. I call it useEffectX. Let’s see the the same example we showed in above codesandbox with our shiny new useEffectX.

Notice now , how we have access to previous values in the arguments of useEffectX’s callback itself. We don’t need any usePrevious hook now plus the arguments are completely optional same with any function. The code snippets below will also work exactly same as official useEffect

useEffectX(() => {
  console.log(val, someotherVal)
}, [val, someotherVal])

useEffectX(() => {
 console.log("do something after every render")
})

Thanks. Please let me know , what you all think about this useEffectX.

simbathesailor / use-effect-x

🌟 useEffectX 🌟 : An alternative and drop-in replacement for useEffect which provide previous values of dependency items out of the box.

use-effect-x

An alternative to useEffect which provide extra info to work with updates

Why it is needed ?

Most of the times we need to respond to updates in our components, where we need to compare previous values and current values. Remember we had the same thing with componentDidUpdate in class based components earlier. useEffect today are not capable to do so out of the box. you need to put in extra effort to get the previous and current values.

We will focus on the function components now, as they are the most prominent way of developing components today.

In functional components we typically make use of usePrevious custom hooks. That definetly works. But, you need to do extra work of adding usePrevious hooks for individual items in useEffect dependency.

What if we have the access of previous and new values in useEffect callback also, so that we dont have…

View on GitHub

https://twitter.com/simbatheesailor

Useful Patterns with React hooks

anil kumar chaudhary — Fri, 27 Dec 2019 11:45:02 +0000

Photo by Sebastian Bednarek on Unsplash

Well, here I am explaining the pattern in React hooks. Who am I ? No body !! Don’t be mad because this is opinionated. Things which worked for me and the people around me.

That’s it.

First let’s take a step back, and understand what changed with react hooks. Well, A lot has changed but we will talk about those things which are going to be relevant for the the discussion ahead.

From now on I will be calling React hooks as just hooks. I am tired of adding React in front of every hook word :).

So the hooks come with a beautiful way of sharing stateful logic between components and also make the reusability of logic much easier. The hooks allows to segregate the logical concerns properly. Remember how we were adding a functionality spread across various lifecycle methods with classes approach.

It is all good, but problem starts when we think how do we share the logic to other components. we then use to take on HOC patterns and render props pattern, which are very good patterns for sharing the logic. But with all goodness, they also bring lot more not needed verbosity and false hierarchy of our components. It also bring in friction to extract reusable logics.

We will not discuss more on class based components. Because I think you are here to see the patterns with hooks and some food for thought.

Hooks are very good, but there are certain thing which can make situations difficult for even a seasoned developer. One of the problem which I used to encounter is with the custom hooks. A simple custom hooks is quite straight forward to work on. But its start’s getting confusing when it takes multiple arguments.

Even multiple arguments are good, but when the argument are objects, array or functions , It becomes very difficult to wrap your head around the hook.

Yes, React has provided certain hooks which allows me to mix and match them and solve the issue. I felt myself putting in a lot of focus and head while writing a custom hook which now has started accepting functions. Damn why I have to be so cautious. Why I can’t just pass functions as make it work. Why the infinite loops are getting triggered, why I have to every time think , Should I use useRef or useCallback ? At the time , I would be like

Yes, but some would say ohh, so you are experienced and you are not able to figure out closures and references. Oh yes my friends, I find myself good with those concepts , but does not like the fact of thinking it every time ,when i am passing references to the hooks. For me custom hooks are just a utility that does processing and return back something which I use in my visual components.

So some might say, I have not felt that way. I am totally ok with how to write hooks. I would say cool, you have got it. May god teach all of us that finesse.

But before we see some code, let’s understand why objects, arrays and especially objects are little complicated with hooks.

My opinion is different for (object, arrays) and different for functions. I would say nothing has changed for objects and arrays as such. If we pass a new reference of arrays or object in class based component, the componentDidUpdate will get triggered. With hooks similarly, a hook with dependencies as arrays or object will rerun and do it’s thing.

But when it comes to functions we are so used to write them as component instance, that function does not change very often with class based component

Notice above how the Child component (SomeChildComponent) is taking two props:

callback : available on instance, does not change on re-render
callback2: same as above

But with hooks, there are no lifecycles now, mental model has changed to an extent.we still write the functions we need to pass on to other hooks or component inside the function. I think that comes natural. It means every time the component re-render the new reference is being passed to the respective hook or components.Btw It has benefits as we are having access to value outside due to closure. Could have been a dragged effort to pull the functions out of the components every time.

Now for simple cases , it’s all ok, but as the logic progresses inside component and the components around it, it demands a lot of focus.

To the readers who are still with me, let’s see some code and understand various ways of handlings references with hooks. We will go through various cases and by the end we will have correct mental model and patterns to work with hooks. Take all these cases below as some of the ways of working with hooks , not all.

We will be taking small examples, base code will not change much across cases except certain parts of them. Every example will have base problem and the ways to fix it.

CASE 1:

Input

Problem : In above code snippet , we are passing fn function as the argument to useFunctionHook. The fn reference changes on every render of component App. It can cause the effect to re-run again even when it is not desired. Let’s give our first try to fix this issue.

CASE 1 TRY 1:

Above we moved out the fn definition and now, it will have same reference across re-render. But it’s not always possible to do. We most of the times need access to the local variables available in Components and custom hooks. Following the approach above , will make it difficult to do so.

CASE 1 TRY 2:

React also gives us a special hook named as useCallback, which allows us to keep the reference intact based on dependency list passed as the second argument. Here is the API for useCallback

const fn = useCallback(function() {}, [a, b, c])

The first argument function is synchronised with the elements in dependency lists. The fn will only point to a new reference when a, b or c changes in this example. Let’s make use of it to solve our problem.

In the example above, now the fn is again part of the component, but now fn has the access to all the variables inside component due to closures. And also the useFunctionHook makes use of useCallback to persist the reference of fn. In the example the reference of fn will not change across re-render.

Now lets say the fn access some value from the component something like this:

But the the fn reference will not change across re-render as the dependency is blank array in our case.

const fnCallback = React.useCallback(fn, [])

So in our case , The count referenced by function fn will refer to same initial value across re-render.

The closures created once will persist across re-renders unless the

callback runs again.

Fix is easy, now add count as the dependency for useCallback. For that we must pass countInparent also now to useFunctionHook.

One more alternate adjustment we could have done here is instead of having memoized the callback in useFunctionHook, we could have done it in App component.

But I think that’s not a good way to go ahead. It’s better if consumer of a custom hook has to do less things to make it work. In our case , we pulled the burden for maintaining the reference to function fn from App component. I think that’s good developer experience.

On the same lines, some may say useRef is also a viable option here. I would say the typical answer which is it depends. So let’s try the solutions with useRef.

CASE 1 TRY 3 :

This approach also work for various scenarios. But there are few things to keep in mind before choosing useRef.

Like useCallback there is no separate dependencies like array, so what could have been achieved with single line may require multiple lines with useRef. we can also write a custom hook like this, which removes some of verbosity from the above code.

Now the above example can be written as :

The ref approach becomes silent dependencies. What do I mean by silent dependencies ? . Let’s see that

useEffect(() => {
 // some logic
}, [refDependency, nonRefDependency1, nonRefDependency2])

Here above , refDependency will never change after first run. But the values refDependency might be carrying will be updated on every run .

const { current: updatedValueAlways } = refDependency
//The value updates always but not the ref(refDependency) reference

But nonRefDependency1 and nonRefDependency2 are non ref dependency which will change when their respective value changes on re-render.

At times, it becomes impossible to trigger rerun of the effect callback on value change.

So if only refDependency.current changes , it will not trigger the effect callback to run because refDependency itself has not changed.

Before, we move ahead let’s see one of the pattern that can used for avoiding the more work from consumers of custom hooks.

CASE 2

Let’s call it ref callback pattern for now(So this name is pretty common, that I have heard recently, but sounds legit). Now let’s observe the code below:

PROBLEM: In the code above , the App holds the responsibility of passing ref to useFunctionHook. But again as discussed above, we should avoid the effort from the consumer of the hook as much as possible. I think same concept applies for almost every thing in programming. So let’s try to do so.

CASE 2 TRY 1 :

Notice above , how we are using the our callback way of setting up ref. We have also pulled out the responsibility of creating ref from the App component.

Now consumers do not need to worry about creating a ref every time to consume the hook. It would be good if we can extract the functionality of creating callback refs in a common hook. Let’s do that.

Now the code changes to this:

To summarise the ways we can handle callbacks with react hooks are:

1. If possible move out the callback outside the component. This will not be possible almost every time. So mind it.

2. If the callback is not dependent on any of the values in component scope, then go for useCallback approach or useRef approach with blank dependencies.Remember they become silent in those cases. Can be tricky as the closure created once will not update itself unless it runs again.

3. If the callback need to change when certain values changes, go for useCallback approach, passing in desired dependencies.

4. Try to minimize the things that consumer of a hook or component have to do to get things working.

Now we talked about various ways of handling functions with custom hooks. Let’s understand how we are going to handle array and objects with custom hooks.

Notice Type 1 and Type 2 versions of useAcceptOptions hook. Doing the Type 1 will make the the debugging difficult. But the Type 2 can be more deterministic and debugging can be easy. For arrays and objects, nothing has changed. Try to avoid putting dependency like this:

It’s very common to pass the options inline , so writing like above will run the callback of effect hook to run every time. Try to keep the options as small set of values. Having big objects and array argument to custom hooks becomes difficult to reason later.

Let’s see one more example having functions, object and arrays in it.

In the example we are just using the knowledge which we have discussed in this article till now. I am not going to explain the code above. I think you should go ahead and read it.

I think mix of useCallback, useRefValues and useCallbackRef solves almost all of the issues.

Feel free to point if any issues with the code snippets above. I have also written a handy library to debug hooks. Feel free to try it and let me know. A babel plugin is also available for it.

As told above, these are my experiences while writing hooks since last year. Please let me know if there are any other good patterns that you guys have been using.

Thanks

Debug your Reactjs Hooks with ease !!

anil kumar chaudhary — Mon, 18 Nov 2019 17:56:01 +0000

Debug your Reactjs Hooks with ease !!

Sanpshot of debug tool that we are going to achieve

I have been working on hooks for quite a long time. I use react hooks every day in my open source projects and also at work.

Now, using useEffect, useCallback, useMemo have really helped me compose the logic well together. But when the dependency list gets long. When I say long , it can be any thing greater than 3 for me and can be more or less for others.

With these large dependency array, I found it really difficult to debug and find out what is causing my useEffect to run again( same for useCallback and useMemo). I know two strategies to debug:

Break the useEffect logic into multiple useEffect. It is still fine, but expertise and time constraints will vary and might be not the efficient solution at the moment. People will not break the useEffect logic into smaller pieces first, they will first try to spend time using console.log and adding debugger to debug the behaviour. No body want their changes cause any regression by breaking the usEffect logic into multiple useEffects.

2) Make use of usePrevious hook which can be defined something like this

And can be consumed like this:

https://gist.github.com/simbathesailor/6defb45314a6015bc1c74a7fb738ba12

However we can do it , it quite too much of work every time you run in the issue , where useEffect callback is running unexpectedly.

To solve the above problem, I tried to create something which can enhance developer experience in this case. Let’s see my try for the above problems.

I created a simple hook which looks for old value and new values and log it appropriately to help. I have also packaged this simple hook in a npm module.

The package can also be used with a babel plugin which make it more easy to debug.

npm i @simbathesailor/use-what-changed --save-dev

npm i @simbathesailor/babel-plugin-use-what-changed --save-dev

Add the plugin entry to your babel configurations

{
 "plugins": ["@simbathesailor/babel-plugin-use-what-changed"]
}

Make sure the comments are enabled for your development build. As the plugin is solely dependent on the comments.

Now to debug a useEffect, useMemo or useCallback. You can do something like this:

// uwc-debug
React.useEffect(() => {
 // console.log("some thing changed , need to figure out")
}, [a, b, c, d]);

// uwc-debug
const d = React.useCallback(() => {
 // console.log("some thing changed , need to figure out")
}, [a, b, d]);

// uwc-debug
const d = React.useMemo(() => {
 // console.log("some thing changed , need to figure out")
}, [a]);

No need to add any import for use-what-changed. Just add a comment //uwc-debug’ above your hooks and you should start seeing use-what-changed debug consoles.

Note: Frankly speaking the whole package was built, cause I was facing problems with hooks and debugging it was eating up a lot of my time. Now I think I feel quite comfortable with hooks. Now I do not need this often, but i think it can be quite useful for debugging hooks. But this hook helps me to write better hooks almost always.

I would suggest to use it with the approach above. But for some reason, if you don’t want to go with babel plugin approach. Follow below steps.

If using npm. Run:
npm i @simbathesailor/use-what-changed --save

If using yarn. Run:
yarn add @simbathesailor/use-what-changed

Note: This hook only logs in the development environment. It make use of standard process.env.NODE_ENV to decide. Open devtools console tab to see the logs.

When only dependency are passed as the single argument

Above snapshot show the console log when b and c has changed in the above code example.

Pass two arguments to useWhatChanged which makes it possible for useWhatChanged to log the names of the variables also.

Color coding

A unique background color will be given to each title text. It helps us in recognising the specific effect when debugging. A unique id is also given to help the debugging further.

If you need to check it live in action and want to play around with it. Go to below codesandbox link

This was my try to solve the problems with reactjs hooks debugging. Hope this helps. Feel free to reach out to me on twitter or github issues for discussions.

My twitter profile:

Anil Chaudhary

use-what-changed npm package link :

@simbathesailor/use-what-changed

Thanks everyone !!