# Parameter Configurator

## Param Config Introduction

In the fascinating world of React applications, engineers often encounter a need to dynamically render user interfaces based on data received in **JSON** format. This is where the idea of a *React JSON Renderer* comes into play. At its core, this concept revolves around the transformation of JSON data into visually engaging React components or other UI elements.

To use our product effectively, users often need to configure numerous settings, a task that involves creating multiple inputs and distributing them across various sections—a repetitive and time-consuming process that can hinder development progress.

This time I will share the process of making param config…

## Param Config Flow

But what exactly is ***Param Config***? From a frontend perspective, *it comprises a set of instructions that dictate which inputs to render, how to render them, and what data they represent*. On the backend, *it defines how the frontend renders data, the rendering methods employed, and the data sources used for these inputs*.

To grasp the concept visually, take a look at the illustration below:

![param-config-flow.png](/uploads/param_config_flow_0e391368c4.png)

## Basic Examples

Let's delve into the example below, where we aim to render two distinct input fields: a dropdown input and a text input.

![param-config-basic.png](/uploads/param_config_basic_d170052ff1.png)

The magic lies in utilizing param config to effortlessly achieve this goal. By constructing an object with two essential keys—namely `field` and `name`—we pave the way for generating the desired input configuration.

```jsx
const response = {
  field: {
    description: "Select column to rename",
    input_type: "dropdown",
    options: {
      display: "name",
      value: "value",
      data: [
        {
          name: "Permalink",
          value: "permalink"
        },
        {
          name: "Company",
          value: "company"
        }
      ]
    }
  },
  name: {
    description: "New name for the column",
    required: true
  }
};
```

This return value is thoughtfully generated by the backend, simplifying the process for seamless frontend rendering.

With param config in place, the frontend gains the power to ***dynamically generate inputs based on specific instructions*** received from the backend, streamlining the development process and offering a flexible and user-friendly interface.

## Param Conifg Feature

Our Param Config is designed to offer flexibility while maintaining clear boundaries within the feature scope. Some properties include advanced features that support various functions like _Layout Grid_, _Conditional Rendering_, and _Dynamic Options_.

These advanced properties open up possibilities. The Layout Grid allows easy arrangement of components for visually stunning displays. Conditional Rendering adds an interesting touch, showing or hiding components based on specific conditions, enhancing the user interface. With Dynamic Options we have the flexibility to either provide a hard-coded data, or utilize Conditional Data Fetching, we can retrieve data only when needed, optimizing performance and efficiency in every interaction.

### Layout Grid

Layout Grid's: effortlessly group multiple inputs in a sleek horizontal stack by adding the special `group_id` identifier. It brings style and organization to your interface, creating a delightful user experience. With Layout Grid, several inputs can be grouped into a horizontal stack. To achieve this you need to append an identifier key `group_id`.

![param-config-layout-grid.png](/uploads/param_config_layout_grid_6042e830f3.png)

*Example above groups “Select Operator” and “Value” with one **`group_id`** to achieve horizontal grid.*

```jsx
const response = {
	select_field: {
		title: "Select Field",
    input_type: "dropdown",
		options: { ...options }
	},
  select_operator: {
		title: "Select Operator",
    input_type: "dropdown",
		group_id: "60416fe",
    options: {
      display: "name",
      value: "value",
      data: [
        {
          name: "Greater Than",
          value: "gt"
        },
        {
          name: "Lesser Than",
          value: "lt"
        }
      ]
    }
  },
  value: {
		title: "Value",
		group_id: "60416fe"
  }
};
```

### Conditional Rendering

Conditional Rendering brings the power of invisibility, hiding multiple inputs from users until specific render conditions are met. When the given criteria aligns, the front-end conjures those inputs into view.

![param-config-conditional-render-2.gif](/uploads/param_config_conditional_render_2_38176ec31e.gif)

```jsx
const response = {
  ssh_auth: {
    title: "SSH authentication",
    description: "Method to authenticate the SSH tunneling",
    input_type: "dropdown",
    options: {
      display: "name",
      value: "value",
      data: [
        {
          name: "Password",
          value: "password"
        },
        {
          name: "SSH Key",
          value: "ssh_pkey"
        }
      ]
    }
  },
  password: {
    title: "SSH Password",
    input_type: "password",
    depends_on: {
      ssh_auth: ["password"]
    }
  },
  ssh_pkey: {
    title: "SSH Key",
    input_type: "file",
    depends_on: {
      ssh_auth: ["ssh_pkey"]
    }
  }
};
```

To make Conditional Rendering work, the Back-end provides the magical `depend_on` key. There's 2 ways of processing `depends_on`. If it's across the *field*/*param* then the condition will translate as `AND`. If it's on the value level (the value is given as an ***Array of string***), then it will translate as `OR`.

<table id="mdx-table">
    <thead>
        <tr>
            <th width="100px">args</th>
            <th width="100px">args.key</th>
            <th>description</th>
            <th width="150px">Data type</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>depends_on</td>
            <td>key</td>
            <td>This property represents which param/field that requires a value before the current param/field is evaluated for render criteria.</td>
            <td>String</td>
        </tr>
        <tr>
            <td>depends_on</td>
            <td>value</td>
            <td>This property represents what criteria has to be met in order the DDL UI can render the current param/field. It supports String (if single value) or Array of String (if multiple value). Also this property accepts a null value.</td>
            <td>String</td>
        </tr>
    </tbody>
</table>



<table id="mdx-table">
    <thead>
        <tr>
            <th width="200px">value</th>
            <th>description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>depends_on: `\{ field_1: null, field_2: null \};`</td>
            <td>**Example of multiple field render condition**: Example on the left translates to `Only render this field, if both field_1 AND field_2 have value`. The null value means that its value doesn’t have to be specific, as long as field_1 and field2 have value. It will render the current param/field.</td>
        </tr>
        <tr>
            <td>depends_on: `\{ field_1: ["gt", "gte"] \};`</td>
            <td>**Example of multiple value render condition**: Example on the left translates to `Only render this field, if field_1 has value either "gt" OR "gte"`. The value has to be specific between `gt` or `gte`.</td>
        </tr>
        <tr>
            <td>depends_on: `\{ field_1: ["gt", "gte"], field_2: null \};`</td>
            <td>**Example of combined render condition**: Example on the left translates to `Only render this field, if field_1 has value either &quot;gt&quot; OR &quot;gte&quot; AND field_2 has any value.`</td>
        </tr>
    </tbody>
</table>

### Dynamic Options

Dynamic Options is used when the front-end requires an `options.data` to be defined from the back-end. Dynamic Options is achieved by the dropdown component making a request call to the back end to supply the options data. Dynamic Options have two way of retrieving data. It could be a **Fixed Option** or **Conditional Data Fetching**.

The **Fixed Option**s feature is employed when the back-end provides a precise parameter value, making it unnecessary to fetch data, making it a simpler alternative to **Conditional Data Fetching**. 

```jsx
const response = {
  ssh_auth: {
    title: "Import method",
    input_type: "dropdown",
    options: {
      display: "alias",
      value: "name",
      data: [
        {
          alias: "Import table",
          name: "table"
        },
        {
          alias: "SQL Query",
          name: "sql"
        }
      ]
    }
  }
};
```


The **Conditional Data Fetching** however, works differently. It retrieves the data to be rendered from the back-end API. It will make an API request and **the request call from the client side will not be executed when certain conditions criteria are not met**. This Conditional Data Fetching prevents the request from being sent without the proper request data. Here’s an example:

```jsx
const response = {
  schema: {
    title: "Schema",
    input_type: "dropdown",
    depends_on: {
      key: "import_method",
      value: "table"
    },
    options: {
      dynamic: true,
      fetch_on: {
        import_method: ["table"]
      }
    }
  },
  table: {
    title: "Table",
    input_type: "dropdown",
    depends_on: {
      key: "import_method",
      value: "table"
    },
    options: {
      dynamic: true,
      args: {
        schema: {
          value: "from_param",
          param: "schema"
        }
      },
      fetch_on: {
        key: "schema"
      }
    }
  }
};
```

![param-config-dynamic-options.gif](/uploads/param_config_dynamic_options_be731d3250.gif)

Let’s take a look at the use case above, we want to be able to import a table from a database, but here the problem lies. In order we’re able to import a table, we need to specify the table schema and the table name. The *table* dropdown input is generated based on the *schema* dropdown value. This is when Conditional Data Fetching on Dynamic Options comes in handy.

Basically, we tell the front-end to not render (Coincidentally this is chained with Conditional Rendering) and not to fetch the data when the param *schema* value is empty (Because in order to fetch the *table* options, *schema* value is required by the back-end API’s in `options.args`).

Here’s what happened: in *table* params, it waits until the *schema* param has a value, when the fetch condition is met– in which the criteria is based on `options.fetch_on.key` and `options.fetch_on.value`, then the front-end makes the API’s (with the `options.args` value that required by the back-end) request to the back-end. That’s exactly how **Conditional Data Fetching** works.

## Behind the thinking

As any man made logical product, this Param Config has several flaws yet a tolerable one. You might wonder why we chose to create a separate key-value pair for Layouting instead of utilizing data structures. Well, the answer lies in our development process. Initially, we embarked on the journey without a clear picture of how the Param Config should be structured. Our main goal was to create a dynamic solution, and along the way, we gained insights into how we wanted it to work and fit into our application.

To avoid over-engineering and accommodate iterative development, we made a decision that required some compromise. We acknowledged that all our engineers needed to familiarize themselves with the JSON Renderer and Param Config first. This approach allowed us to build and refine the feature step by step, ensuring it evolved into the perfect fit for our needs.

Setting boundaries for the Param Config posed the biggest challenge. We wanted the flexibility to make changes swiftly without the need for extensive code replacements or refactoring. Balancing flexibility and structure was key to crafting a solution that truly stood the test of time.


Unleashing the Power of JSON Renderer: Crafting Dynamic and Data-Driven User Interfaces in React Applications

small_article-param-config.jpg

thumbnail_article-param-config.jpg

article-param-config.jpg

Param Config - A Dynamic JSON Renderer

## What is List Virtualization ?

There may be times where we need to display a large list or large table that contains many columns or many rows – *sometimes, even both.* Loading every single item on such a list **can affect performance** significantly. Enter virtualized list —or also know as *“windowing”*, which was a concept of only rendering what is visible to users. This concepts solve the performance problems of rendering large list or table.

## How does List Virtualization Works ?

![virtualized-list-concept.gif](/uploads/virtualized_list_concept_d00600673d.gif)

*"Virtualizing"* a list of items involves **maintaining a window** and **moving that window around your list**. The number of elements that are rendered at first is a very small subset of the entire list and the *"window"* of visible content moves when the user continues to scroll. Let’s put it this way: Imagine you have 1000 list of elements, rather than rendering 1000 of elements — *which can affects performance, because on slower initial rendering or scroll performance.* Instead, You only render 5 elements that visible to the user. By implementing virtualized list, it would benefit the low-end devices. You can display more items as the user scrolls, replacing the previous list element with the new one.

## How to implement List Virtualization ?

There’s several library out there that provides this function. But my top two is by Brian Vaughn, `react-virtualized` and `react-window`. Personally, I would prefer `react-window` over the other just because it’s much smaller and faster. Here’s the comparison:

![react-window_bundlesize.png](/uploads/react_window_bundlesize_7107899753.png)

![react-virtualized_bundlesize.png](/uploads/react_virtualized_bundlesize_45a8311d48.png)

The API’s for both package are relatively similar, but in this case I will use `react-window`.

## List Virtualization Implementation

![list-virtualization.png](/uploads/list_virtualization_83c2683d1e.png)

Lists render a **windowed list (row) of elements** meaning that only the visible rows are displayed to users (e.g **[FixedSizeList](https://react-window.now.sh/#/examples/list/fixed-size)**, **[VariableSizeList](https://react-window.now.sh/#/examples/list/variable-size)**). Lists use a Grid (internally) to render rows, relaying props to that inner Grid.


### Rendering a List of Data using React

There’s 99% chance that you already know how to render list data in React. But for a moment let’s assume that you don’t. Imagine we want to render a list of people, in a scroll-able `div` container. Given a set of data that looks like this:

```jsx
const people = [
  {
    name: "Aditya Kurnia Harapan",
    age: 27
  },
  {
    name: "Azhari Rizkita Priyono",
    age: 24
  },
  //...some other people here
  // and then comes my name
  {
    name: "Irshadi Bagasputro",
    age: 27
  }
  // ...and many more
];

```

In a traditional—React way, we need to do something like this, basically we iterate the whole array/list with a `.map` function. And it will returns the JSX itselfs.

```jsx
const PeopleList = () => {
  return (
    <div>
      {people.map(({ name }) => (
        <Item>{name}</Item>
      ))}
    </div>
  );
};
```

Usually, there won’t be a problem using this traditional approach, but here’s the interesting part. Image the `people` array on the example above, contains a billion of people. What react did is it will **iterate, through every item on the list and it will paint it to the DOM**. This is painful and expensive things that react can do. The longer the list, the more of user’s device performance used. 

### Rendering a Virtualized List of Data using React

One way to prevent this is by using Virtualization **Windowed List**, **instead of iterating through every item on the people array, it will only render several item inside people array**. **Virtualization** **achieve this by lazily paint the item to the DOM as user’s scroll through the scroll-able container**. With the same set of data, now let’s refactor those code using `react-virtualized` .

```jsx
import { List } from "react-virtualized";

const PeopleList = () => {
  const ref = React.useRef();

  // More: https://github.com/bvaughn/react-virtualized/blob/master/docs/List.md#rowrenderer
  const rowRenderer = ({ index }) => <Item>{people[index].name}</Item>;

  return (
    <List
      ref={ref}
      height={600}
      width={300}
      rowCount={people.length}
      rowHeight={40}
      rowRenderer={rowRenderer}
      overscanRowCount={1}
    />
  );
};
```

Let's dive into the code snippet above, and at first glance, we notice that the only missing piece is the looping process, which is expertly handled by the `<List />` component. However, there are a few other mandatory props that we must address, including `height`, `width`, `rowCount`, `rowHeight`, and `rowRenderer`.

Starting with the `rowRenderer` prop, it plays a crucial role in rendering a single row or item, determined by its index in the list. This specialized function allows the item to be virtualized intelligently based on the window or box scanner, optimizing performance by rendering only the visible items on the screen.

The significance of `height` and `width` cannot be overlooked; they define the dimensions of the virtualized _window_ that contains multiple rows. By setting appropriate `height` and `width`, we establish the boundaries within which rows will be efficiently virtualized, ensuring a smooth and seamless user experience, regardless of the size of the underlying data.

`rowHeight` is another vital prop, which can be either a _function_ or a _number_. It comes into play during the scanning process, helping to determine the size of rows within the virtualized window. This information is crucial for the intelligent rendering of rows as the user scrolls through the list.

Lastly, let's talk about the `rowCount` prop. It holds paramount importance in predicting and determining the total height of the list. The calculated total height is derived from the simple formula `rowCount * rowHeight`, and this value aids in detecting the `scroll.x` position based on the window scroller.

By leveraging these essential props in tandem with the `<List />` component, we harness the power of virtualization, allowing us to efficiently handle and display large datasets while maintaining an optimal user experience. The combination of `rowRenderer`, `height`, `width`, `rowHeight`, and `rowCount` culminates in a responsive and high-performing list that dynamically adapts to user interactions.

## Grid Virtualization Implementation

![grid-virtualization.png](/uploads/grid_virtualization_42a301aa0b.png)
Grid renders **tabular data** with virtualization along the X-Axis and Y-Axis — *this means it has both vertical and horizontal virtualization support.* (e.g **[FixedSizeGrid](https://react-window.now.sh/#/examples/grid/fixed-size)** and **[VariableSizeGrid](https://react-window.now.sh/#/examples/grid/variable-size)**). It only renders the Grid cells needed to fill itself based on current horizontal/vertical scroll positions.

### Rendering Grid of Data using React

The next time, I will give an example for Virtualized Grid.

---



In summary, virtualized lists are a powerful optimization technique that improves the rendering performance of long lists in web and mobile applications by rendering only the visible items on the screen, dynamically adjusting the list content as the user scrolls. This results in a smoother user experience, especially when dealing with large datasets.

Virtualization is a performance optimization technique that enhances the rendering of long lists in web and mobile applications by rendering only the visible items on the screen and dynamically adjusting content.

small_article_hero_image_virtualized_list.jpg

thumbnail_article_hero_image_virtualized_list.jpg

article_hero_image_virtualized_list.jpg

Optimize List Performance with Virtualization

## Introduction to Hooks

Before we're going to talk about most use cases of React Hooks, I'm gonna tell you what is React Hooks is,—well, I'm not gonna write about what is react hooks in a full manner of explanation here. But I can tell you what the summary is.

By definition from reactjs official website

> Hooks are functions that let you “hook into” React state and lifecycle features from function components.

So in short hooks are *functions that lets you use react state and lifecycle from components without making it a class components*. It completely replaces Classes React/OOP paradigm with a Functional Programming paradigm.

### Why do I need to use Hooks ?

Surely, it raised one question *Why do we use hooks now ?* or *Why Dan ditch Classes based React for a Functional one ?* I have a good article *(with full proof and explanation)* that you can read [here](https://overreacted.io/how-are-function-components-different-from-classes/). But the main takeaway is React props or state are **always immutable**, but the concept of `this` in Javascript has always been **mutable**.

### Important things when using React Hooks

1. **Always call hooks in the top level of your component.**
2. **Don't call hooks in a loop, conditions, or nested function.**

By doing this, you'll most likely to prevent early return of your components. And your hooks are called in the same order each time your component renders.

So, without further ado, let's talk about React Hooks, and their implementations.

## React.useState

The most common type of hooks that you'll use is `useState`. Pre-Hooks component has a built-in state object where you store property values that belongs to the component. `useState` basically do the same, it is used to store your data, so every-time your component re-render, you can store your data safely inside. If you want to store a data, `useState` is your *goto* guy.

Here's a text input component, designated to change my name, you can implement useState Hooks just like this.

```jsx
import React from "react";

const ReactComponent = () => {
   // Call Hooks ALWAYS on Top Level on the Component
   const [name, setName] = React.useState("");
   
   const handleOnChangeName = e => setName(e.target.value)

   return <input onChange={handleOnChangeName} />;
};
```

`useState` hooks can holds anything, not just a primitive javascript data-type, this means you can also stores array or object. It also can be used with a callback function.

```jsx
import React from "react";

const _userInfoInitialValue = {
   name: "Irshadi",
   age: 25,
   address: "Cilandak"
};

const ReactComponent = () => {
   const [userInfo, setUserInfo] = React.useState(_userInfoInitialValue);
   
   const handleOnChangeUserInfo = ({ key, value }) => {
      setUserInfo(currentUserInfo => {
      // currentUserInfo holds current state of the data in the hooks
      return { 
         ...currentUserInfo,
         [key]: value 
      };
   };

   return (
     <input 
      onChange={e => {
         handleOnChangeUserInfo({ key: "address", value: e.target.value )}
      }} />
    );
};
```

## React.useEffect

Another common Hooks is `useEffect` , It used when you want to perform data fetching, subscriptions or anything that relates to DOM changes. React called this a *side effect—hence effect* for short, because they can and will affect components. In React classes we use `componentDidMount` , `componentDidUpdate` and `componentWillUnmount` . The `useEffect` Hook replaces all of 3 above *(We'll get to that in a minute)*. 

> When you call useEffect, you’re telling React to run your “effect” function after flushing changes to the DOM.
> 

When you're using `useEffect` , you tell React that your component needs to do something after render. By default, `useEffect` **will run on the first and after every update**.

Below, is a component to show whether the user has logged in or not. On component render React will Render this Component, if the `isLoggedIn` state is truthy.

```jsx
import React from "react";

const ReactComponent = () => {
   const [isLoggedIn, setIsLogin] = React.useState(false);

   // Runs on First and After every Update
   React.useEffect(() => {
      // Do Side Effects
      setIsLogin(true);
   });
   
   return ( 
      <div>
      {/* JSX Render */}
      </div>
   );

};
```

### Array Dependencies

The `useEffect` hooks receives two arguments, a function and it signature—array of dependencies. *What ?* *what's that ?* Well, in short it's a way of React to watch things to evaluate things and ask itself, "*Should I re-render ?*". Here's an example

```jsx
import React from "react";

const ReactComponent = () => {
   const [count, setCount] = React.useState(0);
   const [labelText, setLabelText] = React.useState(`Click ${count} Times`);

   // Runs on when counter value changes
   React.useEffect(() => {
      // Do Side Effects
      setLabelText(`Click ${count} Times`);
   }, [count]);
   
   return ( 
      <div>
         <span>Count {count} times</span>
         <button onClick={() => setCount(count++)}>Click Me!</button>
         {/* JSX Render */}
      </div>
   );
};
```

What the code did above, is to tell React to compare the value of state `count` , whether there's a change between previous render and next render *(React does this by comparing DOM and V-DOM)*. If there aren't any differences in dependencies — in this case, `count` state remains the same, React will skip the side effects. If there are multiple items in the dependencies, *React will re-run the effect even if just one of them is different*. Oh and you might want to **avoid object** as dependency.

### Cleanup Values

`useEffect` can also be used for cleanup state or any values in the component. React performs the cleanup when the **component unmount**. All we need to do is to return a function on `useEffect` .

```jsx
import React from "react";

const ReactComponent = () => {
   const [isLoggedIn, setIsLogin] = React.useState(false);
   const [count, setCount] = React.useState(0);
   const [labelText, setLabelText] = React.useState(`Click ${count} Times`);

   // Runs on when counter value changes
   React.useEffect(() => {
      setLabelText(`Click ${count} Times`);
   }, [count, isLoggedIn]);

   // On component unmount reset every state back to 0
   React.useEffect(() => {
      return () => {
         setCount(0);
         setLabelText(`Click 0 Times`);
      };
   }, [isLoggedIn]);
   
   return ( 
      <div>
         <button onClick={() => setIsLogin(false)}>Log Out</button>
         {/* JSX Render */}
      </div>
   );
};
```

## React.useCallback

Remember this code ? Take a second look.

```jsx
import React from "react";

const ReactComponent = () => {
   const [count, setCount] = React.useState(0);
   const [labelText, setLabelText] = React.useState(`Click ${count} Times`);

   // Runs on when counter value changes
   React.useEffect(() => {
      // Do Side Effects
      setLabelText(`Click ${count} Times`);
   }, [count]);
   
   return ( 
      <div>
         <span>Count {count} times</span>
         <button onClick={() => setCount(count++)}>Click Me!</button>
         {/* JSX Render */}
      </div>
   );
};
```

*Wait a minute, I realize something, the code above can be optimized, we can eliminate this* `labelText` *state.* 

```jsx
import React from "react";

const ReactComponent = () => {
   const [count, setCount] = React.useState(0);

   const generateLabelText = () => `Click ${count} Times`

   // Runs on when counter value changes
   React.useEffect(() => {
      generateLabelText();
   }, [count, generateLabelText]);
   
   return ( 
      <div>
         <span>Count {count} times</span>
         <button onClick={() => setCount(count++)}>Click Me!</button>
         {/* JSX Render */}
      </div>
   );
};
```

Well, technically you can, but you can't. Don't believe me ? Go try for yourself.

So you encountered an infinite loop, but *why does this happen ? how can I fix this ?* Okay, Let's start with what's happen. What just happen is—since we put a function in dependencies array—, React is comparing `generateLabelText` function from previous render, with the next render and—*here's the interesting part*— **functions will be re-created on every render.** Thus, React detect an endless state update which cause infinite loop.

There's a several way you can fix this. I'll show you in a minute, but first some of you may be wonder, why you put a function in a dependency array ? The answer is *Why not* ? *and linter told me so*. In React there are some rules that you'll need to follow in order for Hooks to work. React has some built-in *lint*-ing rules that will tell you when you're doing certain things wrong.

```jsx
// A Quick Fix would be
React.useEffect(() => {
   const generateLabelText = () => `Click ${count} Times`
   generateLabelText();
}, [count]);
```

But what happen if we need `generateLabelText` function elsewhere ? Enter `useCallback` Hooks.

What `useCallback` does, is to create a memoization of your function. This means when React compares between next and previous render, your function stays the same. In other words; React doesn't re-create `generateLabelText` function on every render. `useCallback` signature is similar with `useEffect` you have second arguments of dependencies, which acts the same like `useEffect` .

```jsx
import React from "react";

const ReactComponent = () => {
   const [count, setCount] = React.useState(0);

   // Wrap fn inside a useCallback Hook
   const generateLabelText = React.useCallback(() => {
      return `Click ${count} Times`
   }, [count])

   // Runs on when counter value changes
   React.useEffect(() => {
      generateLabelText();
   }, [count, generateLabelText]);
   
   return ( 
      <div>
         <span>Count {count} times</span>
         <button onClick={() => setCount(count++)}>Click Me!</button>
         {/* JSX Render */}
      </div>
   );
};
```

## React.useRef

The last one I want to talk about is `useRef` basically it can be used to store a value, that can be **mutated**, on every render. The value of your *"reference"*, will stay the same between component re-render. On top of that, updating or mutating your value in `useRef` does not trigger a re-render. Just remember ! Reference in `useRef` must be updated either; inside a `useEffect` or a function.

My favorite common use cases for `useRef` are 

1. **Preserve Original Value**
    
    Our first—and my common use case is to *preserve value within every render.* Imagine you have `GET` API, of some details and either `PUT` or `PATCH` API. You need to make a change first from the retrieved value from `GET` API, before you can call  `PUT` or `PATCH` API. And the submit button have a condition if nothing changes, you can't call `PUT` or `PATCH` API. In short  I want to compare original value— from the API, with my modified value — from the state; to control whether the button is disabled or not.
    
    ```jsx
    import React from "react";
    
    const ReactComponent = () => {
       const [data, setData] = React.useState();
       const ref = React.useRef();
       
       // Function for GET some data
       const getData = React.useCallback(async () => {
          // Fetch GET API Here
          const data = await get();
          
          // Save an original value of given data
          ref.current = data;
          setData(data);
       }, [])
       
       const handleOnDataInput = () => {
        let newData = {};
        // Process Data Here
        
        // This will change state data, so the JSX <button /> above, will be enabled
        setData(newData);
       };
    
       React.useEffect(() => {
          getData();
       }, [getData]);
       
       return ( 
          <div>
             <Component data={data} />
             <input onChange={handleOnDataInput} />      
             {/* Logic for disabled condition */}   
             <button disabled={isEqual(ref.current, data)} onClick={editDataToBackend}>
               Save
             </button>
          </div>
       );
    };
    ```
    
    Okay, imagine we have this code. On first `GET` API call, your data is still an original data. `const data = { name: "Irshadi Bagasputro", age: 25 };` and it stores at the `useRef` , when you're trying to change your state *(ie: change age).* The state will be something like this:
    
    ```jsx
    // I did something, in this case change state value, to:
    data = {
       name: "Irshadi Bagasputro",
       age: 26
    };
    
    // But the reference value, is an mutable object, 
    // and we don't call it anywhere, 
    // except on first Render (in useCallback Hooks that only runs one)
    
    // Comparing Original Value and Modified Value
    
    console.log(ref.current)
    // { name: "Irshadi Bagasputro", age: 25 }
    
    console.log(data)
    // { name: "Irshadi Bagasputro", age: 26 }
    
    **// Hence, the button will be enabled**
    ```
    
2. **Capture and Accessing DOM elements**
    
    When you use `useRef` you are given the instance value of the component the ref is attached to. This allows you to interact with the DOM element directly.
    
    My second use case is to store DOM elements. Basically it's like `document.querySelector` in React way.
    
    ```jsx
    import React from "react";
    
    const ReactComponent = () => {
       const ref = React.useRef();
       
       return ( 
          <div ref={ref}>
             {/* JSX Render */}   
          </div>
       );
    };
    ```
    
    When you try to `console.log(ref.current)` it'll become a DOM.
    
    ```jsx
    // This log
    console.log(ref.current);
    
    // Will display you this
    <div class="my_class" />
    
    // And you can basically do anything with vanilla DOM
    
    console.log(ref.current.getClientBoundingRect());
    // { x: 120, y: 120 }
    ```
    

Okay, I guess that's all I can share. I'll see you guys on my next writing ! CIAO~

I write, to taste life twice.

Param Config - A Dynamic JSON Renderer

Optimize List Performance with Virtualization

React Hooks

I write,
to taste life twice.