Often when I look back at a piece of code I wrote long ago, I think that I could have written it 100 times better. I am sure I am not the only one in this boat. As we gain more experience, we constantly evolve our coding practices and design patterns. This is the case with React too.
React also has gone through a lot of transitions, and as it has progressed, certain practices that were believed to be good in the past are no longer fit for the future roadmap. One significant change happened with the release of v16…
When working with React a lot of people expect state changes to reflect immediately both in a class and functional component with React hooks.
This, however, is not the case.
State updates using
useState do not immediately mutate the state but create a pending state transition. Accessing state immediately after calling the updater method can potentially return the old value.
There is no guarantee of synchronous operation of state update calls and multiple state updates can be batched for performance reasons.
State updates alter the virtual DOM and cause re-rendering which may be an expensive operation. …
Debouncing and throttling are two very common terms that we come across when trying to optimize function calls. They can be very useful for improving the performance of user interactions.
Before jumping into the main implementation, let’s understand the basic concepts of
throttle and their real-life use cases (skip ahead if you are already familiar with these concepts).
Debouncing enforces that there is a minimum time gap between two consecutive invocations of a function call.
For example, a
debounce interval of 500ms means that if 500ms hasn’t passed from the previous invocation attempt, we cancel the previous invocation…
The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value.
It can be in one of the three states:
Very often we come across small games and wonder how complex is it? Can we build it? More often than not we do not go beyond it. In this post however we will build a simple memory game which is easy to play and also easy to develop.
The card memory game is a simple game to test the player’s memory. In a deck of paired cards, the player needs to select a matching pair in consecutive turns. The player wins the game when all matching pairs are selected.
A simple UI of it may look like this:
When people talk about Intersection Observer, the most common use cases that come to mind are Lazy loading Images and Infinite Scroll. However Intersection Observer can be put to use in a lot more interactions.
In this post we are going to implement one such interaction, which is a collapsible menu, in which only the items that can take the available space will be shown upfront and rest will go inside the overflow menu.
Frontend enthusiast and an active StackOveflow Contributor