Skip to main content

useCallback hook

Check the code below:

usecallback-demo-1-component-renders-unnecessarily - Code

You can run the app directly:

usecallback-demo-1-component-renders-unnecessarily - App

Whenever the button is clicked, the 'increment rendered' message is logged in console. This means, we're rendering the Increment component unnecessarily.

The Increment component is rendered every time Ã  because it depends on increment method Ã  this method again depends on count state Ã  so, whenever the count state changes, since count state is a dependency of Increment component, this must be rendered everytime.

However, consider the following code where this problem is solved (of course using random number instead of count for demo):

usecallback-demo-2-usecallback-prevents-unnecessary-renders - Code

Here, we're caching the increment method using useCallback hook. The Increment component is not rendered every time. It is rendered only on the initial load.

According to Hooks documentation, useCallback returns a memoized callback.

What does that mean? It means, it returns cached result.

Is that true? In that case, it should always return the same random number when we click the button but we get different values.

So, the above definition should be – it returns cached method (not cached value). This is the reason why though the increment method is called multiple times, the Increment component is rendered only once Ã  because, the Increment component is not dependent on any of the variables inside the increment method (Random is not a dependency but count state is), and it is happy to cache the entire method (callback).

usecallback-demo-2-usecallback-prevents-unnecessary-renders - App

Courtesy: Thanks to this Youtube Video

Comments

Popular posts from this blog

AWS Route53 - Private Hosted Zone

High availability (Multi-AZ) for Amazon RDS

There is something called failover technology in Amazon. AWS RDS's Multi-AZ deployment uses this technology. If you enable Multi-AZ for an RDS DB, say MySQL DB, RDS automatically creates a standby replica in a different AZ. If the primary DB instance is in AZ-1A, then RDS creates a standby replica in AZ-1B (for example). Suppose I add a new row to a table in the primary DB, then the same row is added, almost in the same time, in the standby replica. This is called as synchronous replication . Thus, standby replicas are useful during DB instance failure/ AZ disruption . How? Because, there is no need to create a backup later because the backup has already been created. This gives high availability during planned system maintenance. Normal backup  operation - I/O activities are blocked in the primary database  Automated backup operation (standby replica) - I/O activities are not blocked This standby replica is not similar to read replica (which is used for disaster recovery). S...

Application Load Balancer (ALB)

The ALB spans all subnets in a VPC i.e., it is not inside a subnet but VPC. ALB is bound to Target Groups (TGs). TGs are bound to subnets.