DEV Community: Harsh Choudhary

Analytics slows your sales down, let's fix it!

Harsh Choudhary — Mon, 29 Apr 2024 07:27:04 +0000

This is the first part of this series, where we will learn how to prevent analytics code from slowing down user interactions, which in turn can help improve user experience (UX) and boost sales.

We all know that feeling - we're trying to book something online, but the website is taking forever to load. It's frustrating, right? Slow websites can really kill the mood and make people just give up and go somewhere else. That's why website speed is so important, not just for keeping visitors happy and sales coming in, but also for achieving good Core Web Vitals (CWV) scores that helps with more visibility!

Interaction to Next Paint (INP), which measures how quickly your website responds to user interactions like clicks, is a newly added metric to Core Web Vitals (CWV) that can impact your SEO rankings.

Why Speed Matters?
Did you know that by removing just 100 milliseconds of latency Amazon pulled up sales by 1%? That's a big deal especially looking at the scale they operate at!

Slow websites definitely hurt your bottom line and it's not only about load times - it's about keeping things snappy when people are actually using your site too. If clicks and scrolls feel sluggish, that's a major turn-off.

The Analytics Code Dilemma:

Analytics code execution comes up as one of the main culprit for bad responsiveness to user interactions.

You might be thinking "But I need things like analytics to track how people use my site!" And you're absolutely right. The tricky thing is, all that analytics code can actually be what's slowing your site down in the first place.

The problem lies in the fact that the browser has a single main thread to handle all tasks. This includes rendering the UI, running JavaScript, and executing analytics code. When the analytics code runs on the main thread, it can block other important tasks like responding to user interactions such as clicks and scrolls. This creates a bottleneck, leading to a sluggish and unresponsive experience for your visitors.

The idle until urgent solution:
That's where idlefy comes in. It's a typescript library that helps speed up your site by running analytics code at smart times, when the browser isn't busy with other important tasks. Instead of jamming up the works, idlefy lets your site stay smooth and zippy for visitors.

import {IdleQueue} from 'idlefy';

const queue = new IdleQueue({ ensureTasksRun: true }); 
//ensureTaskRun makes sure the tasks run on visibilitychange event

queue.pushTask(() => {
  // Some expensive function that can be deferred
});

queue.pushTask(() => ga('send', 'pageview'));
queue.pushTask(() => {
   ga('send', 'event', {
      eventCategory: 'Signup Button',
      eventAction: 'click',
   });
});

In the above image it is evident, for the same interaction the code is executed after important stuff is done i.e. responding to user.

It works on the proven idle-until-urgent pattern which under the hood uses requestIdleCallback and it also brings additional goodies out of box such as:

Guaranteed execution of analytics code, even if someone leaves the page
Built with modern TypeScript for safety and better IntelliSense support
Works perfectly with server-side rendering
Tiny file size so it doesn't drag your site down(<2KB gzipped)
Tunable to fit your exact needs

Results:

At Redbus, we used idlefy for more than 2 months and saw amazing results. Our website INP scores improved by almost 50%, from 351 to 179!

That's the kind of speed boost that helped our sales as it kept customers clicking and converting.

If you're ready to zip up your website's performance, give idlefy a shot. It's easy to add to your codebase and the payoff in better UX and higher conversions is totally worth it. Your visitors (and your sales numbers!) will thank you.

Follow me for more such web-performance related stuff and stay tuned for the part 2 of this series where we will offload third-party scripts to web-worker which in return helps us improves load times of our websites.

If you want to read a more detailed version of this blog, visit redbus-blog.

Analytics slows your sales down, let's fix it!

Harsh Choudhary — Sun, 28 Apr 2024 17:58:45 +0000

This is the first part of this series, where we will learn how to prevent analytics code from slowing down user interactions, which in turn can help improve user experience (UX) and boost sales.

Interaction to Next Paint (INP), which measures how quickly your website responds to user interactions like clicks, is a newly added metric to Core Web Vitals (CWV) that can impact your SEO rankings.

Why Speed Matters?
Did you know that by removing just 100 milliseconds of latency Amazon pulled up sales by 1%? That's a big deal especially looking at the scale they operate at!

The Analytics Code Dilemma:

Analytics code execution comes up as one of the main culprit for bad responsiveness to user interactions.

The idle until urgent solution:
That's where [idlefy](https://www.npmjs.com/package/idlefy) comes in. It's a typescript library that helps speed up your site by running analytics code at smart times, when the browser isn't busy with other important tasks. Instead of jamming up the works, idlefy lets your site stay smooth and zippy for visitors.

import {IdleQueue} from 'idlefy';

const queue = new IdleQueue({ ensureTasksRun: true }); 
//ensureTaskRun makes sure the tasks run on visibilitychange event

queue.pushTask(() => {
  // Some expensive function that can be deferred
});

queue.pushTask(() => ga('send', 'pageview'));
queue.pushTask(() => {
   ga('send', 'event', {
      eventCategory: 'Signup Button',
      eventAction: 'click',
   });
});

In the above image it is evident, for the same interaction the code is executed after important stuff is done i.e. responding to user.

It works on the proven idle-until-urgent pattern which under the hood uses requestIdleCallback and it also brings additional goodies out of box such as:

Guaranteed execution of analytics code, even if someone leaves the page
Built with modern TypeScript for safety and better IntelliSense support
Works perfectly with server-side rendering
Tiny file size so it doesn't drag your site down(<2KB gzipped)
Tunable to fit your exact needs

Results:

At Redbus, we used idlefy for more than 2 months and saw amazing results. Our website INP scores improved by almost 50%, from 351 to 179!

That's the kind of speed boost that helped our sales as it kept customers clicking and converting.

If you're ready to zip up your website's performance, give [idlefy](https://www.npmjs.com/package/idlefy) a shot. It's easy to add to your codebase and the payoff in better UX and higher conversions is totally worth it. Your visitors (and your sales numbers!) will thank you.

If you want to read a more detailed version of this blog, visit redbus-blog.

JS Variables 101: Var, Let and Const

Harsh Choudhary — Fri, 21 Jan 2022 11:28:28 +0000

Introduction

Yet another blog explaining Var, Let and Const but I promise this is the only one you need.

ECMASCRIPT2015, also known as ES6 introduced a lot of awesome features. One of the features was the addition of let and const for declaring variables. Previously developers used var for variable declaration, so what was the need of bringing new ones?

If you don't know what let and const brings to the table and how are they different from each other, this blog post is for you. I will compare them based on usage, scope, and hoisting.

Var

Before the introduction of ES6, the only way to define variables in JavaScript was to use the var keyword. For many years, it worked fine, however var differs from other programming languages in terms of variable scoping leading to unwanted bugs that are hard to track.

The below code example demonstrates the declaration of a variable with the var keyword:

var declaredWithVar = "welcome to the blog";
console.log(declaredWithVar);  //welcome to the blog

Scope

The Scope refers to the present context of code, which decides the accessibility of the variables.
The scope is of two types Global and Local:

Variables that are declared outside of a block are known as Global variables.
Variables that are declared inside of a block are known as Local variables.

The variables declared with var are globally scoped when declared outside a function. Any variable declared with var outside of a function block is accessible across the whole window.

var is a function scoped when it is declared within a function which means that it is accessible within that function only.

Look at the example below to understand further:

var globalScopedVar = "declared globally"

function varScopeCheck(){
  var scopingOfVarInFunc = "declared inside function"
  console.log(scopingOfVarInFunc)
}

console.log(scopingOfVarInFunc) //Uncaught ReferenceError: scopingOfVarInFunc is not defined
console.log(varScopeCheck()) //declared inside function
console.log(globalScopedVar) //declared globally

As you can see, we cannot access scopingOfVarInFunc outside of the function as the variable is locally scoped but we can access the globalScopedVar as it is globally scoped.

var can also be redeclared and updated.

This means the value of the variable can be updated by reinitializing and the variable declared with the var keyword can be declared again and again with the same or different values.

Look at the example below to understand further:

var declaredVar = "First time"
var updatedVar = "Old value"

var declaredVar = "Second time"
updatedVar = "New value"

console.log(declaredVar) // Second Time
console.log(updatedVar) // New value

Hoisting

Hoisting is the process by which the interpreter allocates memory for variable and function declarations prior to executing the code. This allows us to use a variable before it has been declared and initialized.

For example:

 console.log(hoistedVar); //undefined
 var hoistedVar = "I'll be hoisted"

why undefined? why not defined error?
var variables are hoisted to the top of the scope and initialized with the value undefined.

Problem with var

var nameUsingVar = "Michael"
if(true){
  var nameUsingVar = 'Mike instead'
}
console.log(nameUsingVar) // Mike instead

In the above code example, global scoped nameUsingVar is replaced by the block-scoped nameUsingVar and we get the unexcepted value. Well, it is not a problem if it's intentional but imagine managing your variables after 1000s of lines of code. This will become tricky to work with and cause a lot of bugs in your code.

That is why let and const were introduced and widely used.

Let

let came as an improvement over var by being block-scoped which solves the problem discussed above.

The below code example demonstrates the declaration of a variable with the let keyword:

let declaredWithLet = "I am preferred over var";
console.log(declaredWithLet);  //I am preferred over var

Scope

Variables declared with let are block-scoped which means that a variable declared in a block with let is only available for use within that block. Variables declared outside blocks are global scoped.

Let's understand it with an example:

let globalScopedLet = "declared globally"

function letScopeCheck(){
  let scopingOfLetInFunc = "declared inside function"
  console.log(scopingOfLetInFunc)
}

console.log(scopingOfLetInFunc) //Uncaught ReferenceError: scopingOfLetInFunc is not defined
console.log(letScopeCheck()) //declared inside function
console.log(globalScopedLet) //declared globally

It solves the problem with var:

let nameUsingLet = 'Michael'
if(true){
    let nameUsingLet = 'Mike'
}
console.log(nameUsingLet) //Michael

As you can see, we get the expected output as it is block scoped.

let cannot be re-declared but can be updated within a scope block.

let nameUsingLet = 'Michael'

let nameUsingLet = 'Mike'
//SyntaxError: Identifier 'greeting' has already been declared

if(true){
  /* This is a different scope, so redeclaration here is ok.*/
    let nameUsingLet = 'Michel'
    console.log(nameUsingLet) //Michel
}

console.log(nameUsingLet) //Michael

Hoisting

let declarations are hoisted but it's different from var.

console.log(variableUsingLet); // ReferenceError: Cannot access 'a' before initialization
console.log(variableUsingVar); // prints undefined as expected
let variableUsingLet = 10;
console.log(variableUsingLet); // 10
var variableUsingVar = 15;
console.log(window.variableUsingLet); // undefined
console.log(window.variableUsingVar); // 15

It looks like let isn't hoisted, but it is, let's understand:
Both variableUsingLet and variableUsingVar are actually initialized as undefined in hoisting stage. But variableUsingVar is inside the storage space of GLOBAL, and variableUsingLet is in a separate memory object called script, where it can be accessed only after assigning some value to it first ie. one can access variableUsingLet only if it is assigned. Thus, it throws a ReferenceError.

Temporal Dead Zone: Time elapsed since the let variable was hoisted until it was initialized with a value.

So any line till before "let variableUsingLet = 10" is the Temporal Dead Zone for variableUsingLet.
Since variableUsingLet is not accessible on global, it's not accessible in window/this also.
ReferenceError is thrown when variables are in the Temporal Dead Zone, SyntaxError doesn't even let us run a single line of code.

Finally, let’s learn about const.

Const

Just like the name, const variables are constant, they cannot be redeclared or updated and if we try to do so, we will get an error.

With only var, the way to signify a constant variable was to write the variable name in all caps but it still could be updated and redeclared. const solves this problem along with var scoping problem.

const variableUsingConst = 10;
variableUsingConst = 20;
console.log(variableUsingConst)
//TypeError: Assignment to constant variable.

Scope

It is also block-scoped and works similarly to let.

const nameUsingConst = 'Michael'
if(true){
    const nameUsingConst = 'Mike'
}
console.log(nameUsingConst) //Michael

Hoisting

It is similarly hoisted as let.

console.log(variableUsingConst); // ReferenceError: Cannot access 'variableUsingConst' before initialization
const variableUsingConst = 10;
console.log(variableUsingConst); // 10

Conclusion

Keyword	Scope	Updateable	Redeclareable	Hoisted
`var`	Function scope	Yes	Yes	Yes
`let`	Block scope	Yes	No	No
`const`	Block scope	No	No	No

Try using const wherever possible.
If not use let, Avoid var.
Declare and initialize all variables with let to the top to avoid errors and shrink the Temporal Dead Zone window to zero.

Stop Building Your UI Components like this❌

Harsh Choudhary — Wed, 22 Dec 2021 13:56:02 +0000

It is true everyone feels elated abstracting the most often copy-pasted code in the codebase into a reusable component. One bad effect of that is hasty abstractions which is a story for another day, today's agenda is to learn how to make actually reusable components.

Lots of the time while abstracting the reusable component it turns into a mess of props. You've probably seen "reusable" components with over 50 props! Those end up being enormously difficult to use and maintain, at the same time it brings performance problems and actual bugs that are hard to track.

Adding one prop for a new use-case is not just an if statement and you end up making a lot of changes in the component making the code size huge and unmaintainable.

But if we're mindful of the kinds of abstractions we create, then we can make something truly easy to use and maintain, is bug-free, and not so big that users pay the download penalty.

Kent C dodd's has explained the problem in-depth, give it a watch:
Simply React

How does a reusable component looks like?

We've got a LoginFormModal component that's abstracted the modal for the login and registration forms. The component itself isn't all that complicated and only accepts a handful of props, but it's pretty inflexible and we'll need to create more modals throughout the application so we want something that's a lot more flexible.

<LoginFormModal
  onSubmit={handleSubmit}
  modalTitle="Modal title"
  modalLabelText="Modal label (for screen readers)"
  submitButton={<button>Submit form</button>}
  openButton={<button>Open Modal</button>}
/>

Towards the end, we will create our component which can be used like this:

<Modal>
  <ModalOpenButton>
    <button>Open Modal</button>
  </ModalOpenButton>
  <ModalContents aria-label="Modal label (for screen readers)">
    <ModalDismissButton>
      <button>Close Modal</button>
    </ModalDismissButton>
    <h3>Modal title</h3>
    <div>Some great contents of the modal</div>
  </ModalContents>
</Modal>

But isn't this more code and more complex than just passing the prop😒.
We have passed the responsibility to the user of the component rather than the creator, this is called inversion of control. It's definitely more code to use than our existing LoginFormModal, but it is simpler and more flexible and will suit our future use cases without getting any more complex.

For example, consider a situation where we don't want to only render a form but
want to render whatever we like. Our Modal supports this, but the
LoginFormModal would need to accept a new prop. Or what if we want the close
button to appear below the contents? We'd need a special prop called
renderCloseBelow. But with our Modal, it's obvious. You just move the
ModalCloseButton component to where you want it to go.

Much more flexible, and less API surface area.

This pattern is called Compound Component - components that work together to form a complete UI. The classic example of this is <select> and <option> in HTML.

It is widely used in many real-world libraries like:

Reach UI
MUI

Let's create our first Compound Component while building a reusable modal.

Building our first compound component

import * as React from 'react'
import VisuallyHidden from '@reach/visually-hidden'

/* Here the Dialog and CircleButton is a custom component 
Dialog is nothing button some styles applied on reach-dialog 
component provided by @reach-ui */
import {Dialog, CircleButton} from './lib'

const ModalContext = React.createContext()
//this helps in identifying the context while visualizing the component tree
ModalContext.displayName = 'ModalContext'

function Modal(props) {
  const [isOpen, setIsOpen] = React.useState(false)

  return <ModalContext.Provider value={[isOpen, setIsOpen]} {...props} />
}

function ModalDismissButton({children: child}) {
  const [, setIsOpen] = React.useContext(ModalContext)
  return React.cloneElement(child, {
    onClick: () => setIsOpen(false),
  })
}

function ModalOpenButton({children: child}) {
  const [, setIsOpen] = React.useContext(ModalContext)
  return React.cloneElement(child, {
    onClick: () => setIsOpen(true),
})
}

function ModalContentsBase(props) {
  const [isOpen, setIsOpen] = React.useContext(ModalContext)
  return (
    <Dialog isOpen={isOpen} onDismiss={() => setIsOpen(false)} {...props} />
  )
}

function ModalContents({title, children, ...props}) {
  return (
    //we are making generic reusable component thus we allowed user custom styles
   //or any prop they want to override
    <ModalContentsBase {...props}>
      <div>
        <ModalDismissButton>
          <CircleButton>
            <VisuallyHidden>Close</VisuallyHidden>
            <span aria-hidden>×</span>
          </CircleButton>
        </ModalDismissButton>
      </div>
      <h3>{title}</h3>
      {children}
    </ModalContentsBase>
  )
}

export {Modal, ModalDismissButton, ModalOpenButton, ModalContents}

Yay! We did quite some work, we can now use the above component like:

<Modal>
     <ModalOpenButton>
         <Button>Login</Button>
     </ModalOpenButton>
     <ModalContents aria-label="Login form" title="Login">
         <LoginForm
            onSubmit={register}
            submitButton={<Button>Login</Button>}
          />
      </ModalContents>
  </Modal>

The code is more readable and flexible now.

Bonus: Allowing users to pass their own onClickHandler

The ModalOpenButton and ModalCloseButton set the onClick
of their child button so that we can open and close the modal. But what if the users
of those components want to do something when the user clicks the button (in
addition to opening/closing the modal) (for example, triggering analytics).

we want to create a callAll method which runs all the methods passed to it like this:

callAll(() => setIsOpen(false), ()=>console.log("I ran"))

I learned this from Kent's Epic React workshop. This is so clever, I love it.

const callAll = (...fns) => (...args) => fns.forEach(fn => fn && fn(...args))

Let's use this in our components:

function ModalDismissButton({children: child}) {
  const [, setIsOpen] = React.useContext(ModalContext)
  return React.cloneElement(child, {
    onClick: callAll(() => setIsOpen(false), child.props.onClick),
  })
}

function ModalOpenButton({children: child}) {
  const [, setIsOpen] = React.useContext(ModalContext)
  return React.cloneElement(child, {
    onClick: callAll(() => setIsOpen(true), child.props.onClick),
  })
}

The power can be used by passing an onClickHandler to our custom button like this:

<ModalOpenButton>
  <button onClick={() => console.log('sending data to facebook ;)')}>Open Modal</button>
</ModalOpenButton>

Conclusion

Don't make hasty abstractions and don't leave everything to props. Maybe it is a simple component now but you don't know what use-cases you would need to cover in future, don't think of this as the trade-off between time and maintainability, the complexity can grow exponentially.

Levitate the power of composition in React with compound components and make your life easier.

Also, check Kent's Epic React Course where I learnt about Compound components patterns and a lot more.

A little about me I am Harsh and I love to code. I have been doing this since 16. I feel at home while building web apps with React. I am currently learning Remix.

If you liked the blog, Let's Connect! I am planning to bring more such blogs in the Future.

Twitter
Linkedin

Know more about me: Harsh choudhary

Check my Testing hooks blog or how to build generic custom hook blog.

Creating A Flip Book Animation With React: The declarative way

Harsh Choudhary — Fri, 17 Dec 2021 07:00:18 +0000

In today's post, we will learn to create a flipbook style animation by converting a simple class-based component into a functional component.

If you used React Hooks for more than a few hours, you probably ran into an intriguing problem: using setInterval just doesn’t work as you’d expect. We will also learn to use it in a more declarative way. More on that later, let's focus on our flipbook nostalgia.

Just like in school with a notebook full of doodles we will be only creating the illusion of movement but hey it’s still pretty fun. Before diving into the nitty-gritty details let’s review the motivation behind this blog.

I stumbled upon this blog when I just started learning React, I found it to be a very simple and interesting approach and challenged myself to convert the class-based implementation into functional components. I migrated the code in minutes but then some issue shot me in the face, I was down for hours searching for answers like why I chose this life, and then Dan's blog resurrected me. Oh wait, I came a long way in the flow, let's rewind.

What are we building?

We are building a component that takes an array of images as a prop and then loop through them to create a moving picture all while retaining the benefits of regular still images on the web.
Like this:

But Harsh we can achieve the same thing with GIF and video, then why so much work? I was out of blog ideas, just kidding, you didn't read that blog? did you? It has explained all the pros and cons of using the different approaches and why the author went with this approach.

Migrating to functional component

Yay! we did it!
I read Dan Abramov's blog thoroughly some days back and realized although our code is working fine, it is not the best way to work with setInterval and he also insists to make it more declarative because you can make arguments “dynamic”, give that blog a read you will understand.

Bonus: The declarative way

The declarative use Interval hook looks like this:

function useInterval(callback, delay) {
  const savedCallback = useRef();

  useEffect(() => {
    savedCallback.current = callback;
  });

  useEffect(() => {
    function tick() {
      savedCallback.current();
    }

    let id = setInterval(tick, delay);
    return () => clearInterval(id);
  }, [delay]);
}

For deep dive into particular part check Dan Abramov's blog .

I used above hook to refactor our code, take a look:

I know using useInterval is overkill for this case but I hope you got something out of it which can help you in future with imperative setInterval pesky behaviour.

A little about me, I am Harsh and I love to play with code and football, I feel at home while building web apps with React. I am currently learning Remix.

If you liked this blog, I am planning to bring more such fun blogs in Future, Let's keep in touch!

Check my Testing hooks blog or how to build generic custom hook blog to manage async code.

Twitter
Linkedin

Check my portfolio: harshkc.tech

A Quick Guide to Testing Custom React Hooks

Harsh Choudhary — Fri, 10 Dec 2021 17:02:37 +0000

The developer on the cover is clearly not looking happy. No no this has nothing to do with Testing.

Testing is Fun ;), and if you hate it maybe I can change your mind, stay with me.

We are utilising our super cool useAsync() hook that we developed in the previous part of the series but you don't need to read them in order to move ahead. This can be treated as a standalone blog on its own but I am categorising it as part 3 of our useAsync() hook series.

The useAsync hook looks like this:

function useSafeDispatch(dispatch) {
  const mounted = React.useRef(false)

  React.useLayoutEffect(() => {
    mounted.current = true
    return () => (mounted.current = false)
  }, [])
  return React.useCallback(
    (...args) => (mounted.current ? dispatch(...args) : void 0),
    [dispatch],
  )
}

const defaultInitialState = {status: 'idle', data: null, error: null}

function useAsync(initialState) {
  const initialStateRef = React.useRef({
    ...defaultInitialState,
    ...initialState,
  })
  const [{status, data, error}, setState] = React.useReducer(
    (s, a) => ({...s, ...a}),
    initialStateRef.current,
  )

  const safeSetState = useSafeDispatch(setState)

  const setData = React.useCallback(
    data => safeSetState({data, status: 'resolved'}),
    [safeSetState],
  )
  const setError = React.useCallback(
    error => safeSetState({error, status: 'rejected'}),
    [safeSetState],
  )
  const reset = React.useCallback(
    () => safeSetState(initialStateRef.current),
    [safeSetState],
  )

  const run = React.useCallback(
    promise => {
      if (!promise || !promise.then) {
        throw new Error(
          `The argument passed to useAsync().run must be a promise. Maybe a function that's passed isn't returning anything?`,
        )
      }
      safeSetState({status: 'pending'})
      return promise.then(
        data => {
          setData(data)
          return data
        },
        error => {
          setError(error)
          return Promise.reject(error)
        },
      )
    },
    [safeSetState, setData, setError],
  )

  return {
    isIdle: status === 'idle',
    isLoading: status === 'pending',
    isError: status === 'rejected',
    isSuccess: status === 'resolved',
    setData,
    setError,
    error,
    status,
    data,
    run,
    reset,
  }
}

export {useAsync}

Give it a read, it is fairly simple to understand and if you want to deep dive into a particular part, check part 2 here which is a thorough guide covering ideation to implementation and optimization.

We want to write a test for this so we can maintain confidence that as we make changes and fixes bugs we don't break existing functionality. To get the maximum confidence we need, we should ensure that our tests resemble the way the software will be used. The software is all about automating things that we don't want to or cannot do manually. Tests are no different, so consider how you would test this manually, then write your test to do the same thing.

You might be saying "Well hooks are functions only, we can unit test them."
Can we?

Hooks are not ** pure** functions, else if it was pure, then it would be a simple task of calling it and asserting on the output.
Also by simply calling the function in a test, we'll break the rules of hooks and we'll be greeted withError: Invalid hook call.

Kent (creator of the react-testing library) advises to not test custom hooks separately and recommends running them as part of integration tests with other components. Doing this will also help avoid our natural tendency to over-abstract our custom hook to support things that your components don't actually need. However, highly reusable or complex hooks can really benefit from a solid suite of tests dedicated to them specifically.

Taking his words, we should stay away from testing hooks separately if they are fairly simple and try to cover them in the integration tests while testing the component. But ours is not that simple and the component that we need to write can be pretty complicated and we can end up getting test failures not because the hook is broken, but because of the example, we wrote.

Hell Yeah! Now we know what to test and why to test!

We have two approaches:

Create a test component that uses the hook in the typical way the hook would
be used by consumers and test that component.
Use @testing-library/reacthooks

In this blog, we will cover the second approach using react-testing-library.

Before we jump straight into testing let's create a helper deferred method for mocking JavaScript Promise behavior.

function deferred() {
  let resolve, reject
  const promise = new Promise((res, rej) => {
    resolve = res
    reject = rej
  })
  return {promise, resolve, reject}
}

It is a simple method with which we can imperatively resolve or reject whenever we want.

const {promise, resolve,reject} = deferred()
//resolve
const fakeResolvedValue = Symbol('some resolved value')
run(promise)
resolve(resolvedValue)
await promise

//reject
const rejectedValue = Symbol('rejected value')
run(promise)
reject(rejectedValue)
await promise.catch(() => {
      /* ignore error */
    })

You would have got a fair idea, things will get more clear once we start testing.

Testing Time

import {renderHook} from '@testing-library/react-hooks'
import {useAsync} from '../hooks'

test('calling run with a promise which resolves', async () => {
  const {promise, resolve} = deferred()
  //this is how we can render the hook using the library
  const {result} = renderHook(() => useAsync())
  //try console logging result.current and see what exactly is the result object
  console.log(result)
}

This is what it prints:

{
        isIdle: true,
        isLoading: false,
        isError: false,
        isSuccess: false,
        setData: [Function (anonymous)],
        setError: [Function (anonymous)],
        error: null,
        status: 'idle',
        data: null,
        run: [Function (anonymous)],
        reset: [Function (anonymous)]
}

This looks like what our hook will assign upon initialisation or we can say default state.

Function(anonymous) is not of our concern, basically, it says that it is some function and we don't need to know much more than that. So, we will assert them using expect.any(Function) and our job is done.

Also, let's create a default, pending, resolved and rejected state object for our ease.

const defaultState = {
  status: 'idle',
  data: null,
  error: null,

  isIdle: true,
  isLoading: false,
  isError: false,
  isSuccess: false,

  run: expect.any(Function),
  reset: expect.any(Function),
  setData: expect.any(Function),
  setError: expect.any(Function),
}

const pendingState = {
  ...defaultState,
  status: 'pending',
  isIdle: false,
  isLoading: true,
}

const resolvedState = {
  ...defaultState,
  status: 'resolved',
  isIdle: false,
  isSuccess: true,
}

const rejectedState = {
  ...defaultState,
  status: 'rejected',
  isIdle: false,
  isError: true,
}

Now everything is set, so let's complete our tests.

TEST 1: Calling run with a promise which resolves

test('calling run with a promise which resolves', async () => {
  const {promise, resolve} = deferred()
  const {result} = renderHook(() => useAsync())
  expect(result.current).toEqual(defaultState)
  /* we will pass our promise to run method and check if we are getting 
      pending state or not */
  let p
  act(() => {
    p = result.current.run(promise)
  })
  expect(result.current).toEqual(pendingState)

/* We are resolving our promise and asserting if the value is 
    equal to resolvedValue */

 const resolvedValue = Symbol('resolved value')
  await act(async () => {
    resolve(resolvedValue)
    await p
  })
  expect(result.current).toEqual({
    ...resolvedState,
    data: resolvedValue,
  })

 // asserting if reset method is working or not
  act(() => {
    result.current.reset()
  })
  expect(result.current).toEqual(defaultState)
})

What is the act here?

In short,

act() makes sure that anything that might take time - rendering, user events, data fetching - within it is completed before test assertions are run.

Yay! our first test on its own has made us so confident in our hook. It has tested the complete happy path from initialisation to resolution and even resetting of state.
But we will be more confident when the hook passes the promise rejection test, the sad path :(.

TEST 2: Calling run with a promise which rejects

test('calling run with a promise which rejects', async () => {
  const {promise, reject} = deferred()
  const {result} = renderHook(() => useAsync())
  expect(result.current).toEqual(defaultState)
  let p
  act(() => {
    p = result.current.run(promise)
  })
  expect(result.current).toEqual(pendingState)
 /* same as our first test till now but now we will reject the promise
     assert for rejectedState with our created rejected value */
  const rejectedValue = Symbol('rejected value')
  await act(async () => {
    reject(rejectedValue)
    await p.catch(() => {
      /* ignore error */
    })
  })
  expect(result.current).toEqual({...rejectedState, error: rejectedValue})
})

Notice that how our tests are resembling with how our software will be used in the real world. This way we are making sure that we're focusing our efforts in the right place and not testing at too low of a level unnecessarily.

I will not write all the tests as it will make the blog too long, feel free to check all the tests implementation on Github.

Try implementing the below tests yourself and if you face any doubt or problems, feel free to ask in the comments or DM me:

TEST 3: can specify an initial state
TEST 4: can set the data
TEST 5: can set the error
TEST 6: No state updates happen if the component is unmounted while pending
TEST 7: calling "run" without a promise results in an early error

A little about me, I am Harsh and I love to code, I feel at home while building web apps in React. I am currently learning Remix.

If you liked this blog, I am planning to bring more such blogs in Future, Let's keep in touch!

Twitter
Linkedin

Check my portfolio: harshkc.tech

Are your custom hooks really generic?

Harsh Choudhary — Tue, 07 Dec 2021 07:59:21 +0000

Part 1 got a solid response, if you haven't checked that out go ahead, it shows how this hook can help you write clean, robust and readable code.

But as promised this part is the real deal, we will not only learn how to think and build such an awesome hook but also learn how to develop true generic custom hooks.

The menu for the day:

Extracting logic from component to custom hook
Making the hook more generic
Making reducer method super elegant 🎨
Making the hook robust 💎
Implementing reset state functionality

Tons of stuff, Fasten your seat-belt we are in for some ride!

We used the final version of our hook to refactor the BookInfo component in the last part, also explained what these components are and what they are doing. If you haven't still read that, go check that out first, here.

import * as React from 'react'
import {
  fetchBook,
  BookInfoFallback,
  BookForm,
  BookDataView,
  ErrorFallback,
} from '../book'

function BookInfo({bookName}) {
  const [status, setStatus] = React.useState('idle')
  const [book, setBook] = React.useState(null)
  const [error, setError] = React.useState(null)

  React.useEffect(() => {
    if (!bookName) {
      return
    }
    setStatus('pending')
    fetchBook(bookName).then(
      book => {
        setBook(book)
        setStatus('resolved')
      },
      error => {
        setError(error)
        setStatus('rejected')
      },
    )
  }, [bookName])

  if (status === 'idle') {
    return 'Submit a book'
  } else if (status === 'pending') {
    return <BookInfoFallback name={bookName} />
  } else if (status === 'rejected') {
    return <ErrorFallback error={error}/>
  } else if (status === 'resolved') {
    return <BookDataView book={book} />
  }

  throw new Error('This should be impossible')
}

function App() {
  const [bookName, setBookName] = React.useState('')

  function handleSubmit(newBookName) {
    setBookName(newBookName)
  }

  return (
    <div className="book-info-app">
      <BookForm bookName={bookName} onSubmit={handleSubmit} />
      <hr />
      <div className="book-info">
        <BookInfo bookName={bookName} />
      </div>
    </div>
  )
}

export default App

Extracting the logic into a custom hook

Plan A:

We will decouple the effects and state from the BookInfo component and manage them in our custom hook only, we will let users(users of hooks) pass just a callback method and dependencies and the rest will be managed for them.

Here's how our useAsync hook looks like now:

function useAsync(asyncCallback, dependencies) {
  const [state, dispatch] = React.useReducer(asyncReducer, {
    status: 'idle',
    data: null,
    error: null,
  })

  React.useEffect(() => {
    const promise = asyncCallback()
    if (!promise) {
      return
    }
    dispatch({type: 'pending'})
    promise.then(
      data => {
        dispatch({type: 'resolved', data})
      },
      error => {
        dispatch({type: 'rejected', error})
      },
    )
  }, dependencies)

  return state
}

function asyncReducer(state, action) {
  switch (action.type) {
    case 'pending': {
      return {status: 'pending', data: null, error: null}
    }
    case 'resolved': {
      return {status: 'resolved', data: action.data, error: null}
    }
    case 'rejected': {
      return {status: 'rejected', data: null, error: action.error}
    }
    default: {
      throw new Error(`Unhandled action type: ${action.type}`)
    }
  }
}

Notice how asyncReducer is declared and defined below it is called. JS feels like magic, not much if you know about Hoisting, if you don't, check this out.

And now we can use our hook like:

function BookInfo({bookName}) {
const state = useAsync(
    () => {
      if (!BookName) {
        return
      }
      return fetchBook(BookName)
    },
    [BookName],
  )

const {data: Book, status, error} = state

//rest of the code same as above

This looks good but this is nowhere near our final version and it has some shortcomings:

Unfortunately, the ESLint plugin is unable to determine whether the dependencies argument is a valid argument for useEffect, normally it isn't bad we can just ignore it and move on. But, there’s a better solution.

Instead of accepting dependencies to useAsync, why don’t we just treat the asyncCallback as a dependency? Any time it changes, we know that we should call it again. The problem is that because it depends on the bookName which comes from props, it has to be defined within the body of the component, which means that it will be defined on every render which means it will be new every render. Phew, This is where React.useCallback comes in!

useCallback accepts the first argument as the callback we want to call, the second argument is an array of dependencies which is similar to useEffect, which controls returned value after re-renders.
If they change, we will get the callback we passed, If they don't change, we’ll get the callback that was returned the previous time.

function BookInfo({bookName}) {
const asyncCallback = React.useCallback(() => {
    if (!BookName) {
      return
    }
    return fetchBook(BookName)
  }, [BookName])
}

const state = useAsync(asyncCallback)
//rest same

Making the hook more generic

Plan B:

Requiring users to provide a memoized value is fine as we can document it as part of the API and expect them to just read the docs 🌚. It’d be way better if we could memoize the function, and the users of our hook don’t have to worry about it.

So we are giving all the power back to the user by providing a (memoized) run function that people can call in their own useEffect and manage their own dependencies.

If you don't know about memoization check this thread here.

Now the useAsync hook look like this :

//!Notice: we have also allowed users(hook user) to send their own initial state
function useAsync(initialState) {
  const [state, dispatch] = React.useReducer(asyncReducer, {
    status: 'idle',
    data: null,
    error: null,
    ...initialState,
  })

  const {data, error, status} = state

  const run = React.useCallback(promise => {
    dispatch({type: 'pending'})
    promise.then(
      data => {
        dispatch({type: 'resolved', data})
      },
      error => {
        dispatch({type: 'rejected', error})
      },
    )
  }, [])

  return {
    error,
    status,
    data,
    run,
  }
}

Now in the BookInfo component:

function BookInfo({bookName}) {
 const {data: book, status, error, run} = useAsync({
    status: bookName ? 'pending' : 'idle',
  })

 React.useEffect(() => {
    if (!bookName) {
      return
    }
    run(fetchBook(bookName))
  }, [bookName, run])
.
.
.
}

Yay! We have made our own basic custom hook for managing Async code.

Now, let's add some functionality and make it more robust.

Making reducer method super elegant 🎨

Our asyncReducer looks like this:

function asyncReducer(state, action) {
  switch (action.type) {
    case 'pending': {
      return {status: 'pending', data: null, error: null}
    }
    case 'resolved': {
      return {status: 'resolved', data: action.data, error: null}
    }
    case 'rejected': {
      return {status: 'rejected', data: null, error: action.error}
    }
    default: {
      throw new Error(`Unhandled action type: ${action.type}`)
    }
  }
}

Have a look at it for a minute.
Notice that we are overdoing stuff by checking action.type and manually setting different objects of the state according to it.

Look at the refactored one:

const asyncReducer = (state, action) => ({...state, ...action})

Wth did just happen?

This does the same thing as previous, we have leveraged the power of JavaScript and made it elegant.
We are spreading the previous state object and returning the latest one by spreading our actions, which automatically handles collisions and gives more priority to actions because of their position.

Making the hook robust

Consider the scenario where we fetch a book, and before the request finishes, we change our mind and navigate to a different page. In that case, the component would unmount but when the request is finally completed, it will call dispatch, but because the component is unmounted, we’ll get this warning from React:

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

To overcome this we can prevent dispatch from being called if the component is unmounted.
For this, we will use React.useRef hook, learn more about it here.

function useSafeDispatch(dispatch) {
  const mountedRef = React.useRef(false)

  // to make this even more generic we used the useLayoutEffect hook to
  // make sure that we are correctly setting the mountedRef.current immediately
  // after React updates the DOM. Check the fig below explaining lifecycle of hooks.
  // Even though this effect does not interact
  // with the dom another side effect inside a useLayoutEffect which does
  // interact with the dom may depend on the value being set
  React.useLayoutEffect(() => {
    mountedRef.current = true
    return () => {
      mountedRef.current = false
    }
  }, [])

  return React.useCallback(
    (...args) => (mountedRef.current ? dispatch(...args) : void 0),
    [dispatch],
  )
}

Now, we can use the method like this:

const dispatch = useSafeDispatch(oldDispatch)

We are setting mountedRef.current to true when component is mounted and false when it is unmounted by running cleanup effects.

See the below fig to learn the lifecycle of hooks.
Notice how layoutEffects are executed way before useEffects.

Implementing reset method

function useAsync(initialState) {
  const initialStateRef = React.useRef({
    ...defaultInitialState,
    ...initialState,
  })

  const [{status, data, error}, unsafeDispatch] = React.useReducer(
    (s, a) => ({...s, ...a}),
    initialStateRef.current,
  )

  const dispatch = useSafeDispatch(unsafeDispatch)

  const reset = React.useCallback(
    () => dispatch(initialStateRef.current),
    [dispatch],
  )

We used refs as they don't change between re-renders.
Basically, we are storing initialState in a ref and the reset method sets the state to initialState upon calling, pretty self-explanatory stuff.

We are almost done with our hook, we just need to wire up things together. Let's review what we have implemented till now:

functionality to handle async code
functionality to handle success, pending, and error state
memoization for efficiency
functionality to pass own custom initialState
functionality to reset current state
Safe dispatch to handle calling of dispatch method upon mounting and unmounting

Phew, that is a lot of work and I hope you are enjoying it.

Wiring things together

After wiring everything, the useAsync hook looks like this:

function useSafeDispatch(dispatch) {
  const mounted = React.useRef(false)

  React.useLayoutEffect(() => {
    mounted.current = true
    return () => (mounted.current = false)
  }, [])
  return React.useCallback(
    (...args) => (mounted.current ? dispatch(...args) : void 0),
    [dispatch],
  )
}

const defaultInitialState = {status: 'idle', data: null, error: null}

function useAsync(initialState) {
  const initialStateRef = React.useRef({
    ...defaultInitialState,
    ...initialState,
  })
  const [{status, data, error}, setState] = React.useReducer(
    (s, a) => ({...s, ...a}),
    initialStateRef.current,
  )

  const safeSetState = useSafeDispatch(setState)

  const setData = React.useCallback(
    data => safeSetState({data, status: 'resolved'}),
    [safeSetState],
  )
  const setError = React.useCallback(
    error => safeSetState({error, status: 'rejected'}),
    [safeSetState],
  )
  const reset = React.useCallback(
    () => safeSetState(initialStateRef.current),
    [safeSetState],
  )

  const run = React.useCallback(
    promise => {
      if (!promise || !promise.then) {
        throw new Error(
          `The argument passed to useAsync().run must be a promise. Maybe a function that's passed isn't returning anything?`,
        )
      }
      safeSetState({status: 'pending'})
      return promise.then(
        data => {
          setData(data)
          return data
        },
        error => {
          setError(error)
          return Promise.reject(error)
        },
      )
    },
    [safeSetState, setData, setError],
  )

  return {
    isIdle: status === 'idle',
    isLoading: status === 'pending',
    isError: status === 'rejected',
    isSuccess: status === 'resolved',
    setData,
    setError,
    error,
    status,
    data,
    run,
    reset,
  }
}

export {useAsync}

Yay, we are done.🎉

That was huge, and I hope you are more excited than tired and I hope you got to learn something new today.
Legends say

"People need to write or teach what they have learned to remember it."

Why don't use the comment section as your writing pad and write your finding, also if you have some criticism, suggestions? feel free to write.

This hook is used extensively throughout Kent C. Dodds Epic React Course. He teaches a lot of cool and advanced topics in his course, he is the author of this hook and I have learned to build it from scratch from his course.

A little about me, I am Harsh and I love to code, I feel at home while building web apps in React. I am currently learning Remix. Also, I am looking for a Front-end developer role, if you have an opening, DM me on Twitter.

I am so excited for part 3, we will be writing tests yay.

I am also planning to share my learning through such blogs in Future, Let's keep in touch!✌️

Twitter Linkedin

Check other blogs of the series!

I promise this hook will blow your 1000+ lines of Async code

Harsh Choudhary — Thu, 02 Dec 2021 07:22:30 +0000

No pun intended there! ;)

The useAsync() hook which I learned to build from Kent's Epic React Workshop looks like this:

function useSafeDispatch(dispatch) {
  const mounted = React.useRef(false)

  React.useLayoutEffect(() => {
    mounted.current = true
    return () => (mounted.current = false)
  }, [])
  return React.useCallback(
    (...args) => (mounted.current ? dispatch(...args) : void 0),
    [dispatch],
  )
}

const defaultInitialState = {status: 'idle', data: null, error: null}

function useAsync(initialState) {
  const initialStateRef = React.useRef({
    ...defaultInitialState,
    ...initialState,
  })
  const [{status, data, error}, setState] = React.useReducer(
    (s, a) => ({...s, ...a}),
    initialStateRef.current,
  )

  const safeSetState = useSafeDispatch(setState)

  const setData = React.useCallback(
    data => safeSetState({data, status: 'resolved'}),
    [safeSetState],
  )
  const setError = React.useCallback(
    error => safeSetState({error, status: 'rejected'}),
    [safeSetState],
  )
  const reset = React.useCallback(
    () => safeSetState(initialStateRef.current),
    [safeSetState],
  )

  const run = React.useCallback(
    promise => {
      if (!promise || !promise.then) {
        throw new Error(
          `The argument passed to useAsync().run must be a promise. Maybe a function that's passed isn't returning anything?`,
        )
      }
      safeSetState({status: 'pending'})
      return promise.then(
        data => {
          setData(data)
          return data
        },
        error => {
          setError(error)
          return Promise.reject(error)
        },
      )
    },
    [safeSetState, setData, setError],
  )

  return {
    isIdle: status === 'idle',
    isLoading: status === 'pending',
    isError: status === 'rejected',
    isSuccess: status === 'resolved',

    setData,
    setError,
    error,
    status,
    data,
    run,
    reset,
  }
}

export {useAsync}

We will be using our hook to refactor the BookInfo component below and make it more elegant and robust by blowing multiple lines of code.💣

import * as React from 'react'
import {
  fetchBook,
  BookInfoFallback,
  BookForm,
  BookDataView,
  ErrorFallback,
} from '../book'

function BookInfo({bookName}) {
  const [status, setStatus] = React.useState('idle')
  const [book, setBook] = React.useState(null)
  const [error, setError] = React.useState(null)

  React.useEffect(() => {
    if (!bookName) {
      return
    }
    setStatus('pending')
    fetchBook(bookName).then(
      book => {
        setBook(book)
        setStatus('resolved')
      },
      error => {
        setError(error)
        setStatus('rejected')
      },
    )
  }, [bookName])

  if (status === 'idle') {
    return 'Submit a book'
  } else if (status === 'pending') {
    return <BookInfoFallback name={bookName} />
  } else if (status === 'rejected') {
    return <ErrorFallback error={error}/>
  } else if (status === 'resolved') {
    return <BookDataView book={book} />
  }

  throw new Error('This should be impossible')
}

function App() {
  const [bookName, setBookName] = React.useState('')

  function handleSubmit(newBookName) {
    setBookName(newBookName)
  }

  return (
    <div className="book-info-app">
      <BookForm bookName={bookName} onSubmit={handleSubmit} />
      <hr />
      <div className="book-info">
        <BookInfo bookName={bookName} />
      </div>
    </div>
  )
}

export default App

I am suuppperrr excited, let's do this!

But before we move ahead let's get on the same page.

fetchBook fetches data from the API and results in Promise which returns book data on resolution and error on rejection.
BookInfoFallback is your loader component that accepts bookName to display a nice loading effect.
BookForm is a simple form component that takes data from users.
BookDataView is a nice looking component that displays the Book data to the user.
ErrorFallback to show nice looking UI with Error.

Implementation of these components is beyond this blog but they are just regular stuff.

What the hell our code is doing?

It is taking the bookName from the user and passing that to the BookInfo component which handles fetching of the bookData in the useEffect hook which sets the state according to different conditions, it also handles the rendering of BookDataView upon successful fetching, ErrorFallback on failure, and BookInfoFallback while loading.

Ok I might have triggered

"Talk is cheap, show me the code" moment.

import * as React from 'react'
import {
  fetchBook,
  BookInfoFallback,
  BookForm,
  BookDataView,
  ErrorFallback,
} from '../book'
import useAsync from '../utils';

function BookInfo({bookName}) {
  /////////////// Focus from here /////////////////
  const {data: book, isIdle, isLoading, isError, error, run} = useAsync()

  React.useEffect(() => {
     if (!pokemonName) {
       return
     }
     run(fetchPokemon(pokemonName))
  }, [pokemonName, run])

  if (isIdle) {
    return 'Submit a book'
  } else if (isLoading) {
    return <BookInfoFallback name={bookName} />
  } else if (isError) {
    return <ErrorFallback error={error}/>
  } else if (isSuccess) {
    return <BookDataView book={book} />
  }
 //////////////// To here /////////////////

  throw new Error('This should be impossible')
}

function App() {
  const [bookName, setBookName] = React.useState('')

  function handleSubmit(newBookName) {
    setBookName(newBookName)
  }

  return (
    <div className="book-info-app">
      <BookForm bookName={bookName} onSubmit={handleSubmit} />
      <hr />
      <div className="book-info">
        <BookInfo bookName={bookName} />
      </div>
    </div>
  )
}

export default App

Woah isn't that neat now, not only does it make our code more readable, we have made our component more robust by not calling the dispatch when the component is unmounted, also we have memoized our fetch method to save network calls if the bookName doesn't change.

But but Harsh aren't we writing more code to accomplish pretty common stuff?

Yes, we are but by writing that hook we can refactor multiple components throughout the project using Async code like that, see in terms of cumulative time saved, less code shipped and high confidence gain.

This is the first part of the useAsync() hook which demonstrates its use cases.

In the next, we will decouple the hook and build it from scratch explaining each line and learning neat tricks.

We will also test the hook in part 3 because why not?

Are you excited about the real deal in part 2? Do tell in the comments and share this article with your friends and excite them too.

A little intro about me, I want to make the world a better place through innovative and quality software.
Does that sound familiar?
Yeah, I am a big Kent C. Dodds fan, he is an inspiration for many.

This hook is used extensively throughout his Epic React workshop. Go check out his awesome course here.

I am also planning to share my learnings through such blogs in Future, Let's keep in touch!

Portfolio Twitter Linkedin

Also don't forget to check other blogs of the series!