How to manage file storage using GridFS with Node.js/Express js, Mongodb, Mongoose and Multer ?

Hooks were introduced in React 16.8 in late 2018 to overcome the difficulties of React to “attach” reusable behavior to a component. They allow to extract stateful logic from a component and make it reusable by many components. In doing that, they allow component to reuse stateful logic without changing its hierarchy.

In this article, we will explore how to test a custom React using Jest and React Testing Library.

### What will our hook ?

We are going to create a hook that :

- Takes an initial ******************count****************** as its argument
- Creates a **count** state and set the inital count as its initial value
- Returns the count state and two functions that increment and decrement the count state.

```javascript
import { useState } from "react";

export function useCounter(initialCount = 0) {
 const [count, setCount] = useState(initialCount);
 const increment = () => setCount((prevCount) => prevCount + 1);
 const decrement = () => setCount((prevCount) => prevCount - 1);
 return { count, increment, decrement };
}
```

### Defining the Test Cases

Before we start testing this hook, let's first look at the blueprint of what we want to test. Now that you know what you want the Hook to do, here's our hook tesing plan:

- When the hook is rendered
- After the *increment* function is called, the counter state is updated with its previous value plus (+) 1
- After the *decrement* function is called, the counter state is updated with its previous value minus (-) 1

### The approches that will not work

**❌ Using RTL’s render method**

We can not use RTL’s *render* method because *render* method is used to render components and only components. As our hook is not a component, we will get an error.

```javascript
import { render } from "@testing-library/react";
import { useCounter } from "./useCounter";

describe("useCounter", () => {
 test("Should render the initial count with 0", () => {
 render(useCounter);
 });
});
```
**❌Calling the hook directly inside the test** 

Calling a hook inside a normal function will cause an error because a hook can only be called from React function components or from custom Hooks.

```javascript
import { render} from "@testing-library/react";
import { useCounter } from "./useCounter";

describe("useCounter", () => {
 test("Should render the initial count with 0", () => {
 useCounter();
 });
});
```
### ✅ Testing Hooks With *renderHook*

The best way to test a custom hook, we use the *renderHook* function of RTL. It takes two parameters :

- *callback*: a that is called each render of the test component. This function should call one or more hooks for testing. The props passed into the callback will be the ***initialProps*** provided in the options to renderHook, unless new props are provided by a subsequent rerender call.
- *options (Optional)*: An options object to modify the execution of the callback function.

The renderHook function returns an object that contains many properties among them the **result** object which contains a **current** property that is also an object containing the returned values of the custom hook. Let's take a closer look:

```javascript
import { renderHook } from "@testing-library/react";
import { useCounter } from "./useCounter";

describe("useCounter", () => {
 test("Should accept and render the same initial count", () => {
 const { result } = renderHook(useCounter, { initialProps: { initialCount: 10 }});
 expect(result.current.count).toBe(10);
 });
});
```

Here we called our hook *useCounter* with its *initialCount* argument value to *10* then we check that the *count* state is updated with *10*.

### Update the **count** state

Let’s try to update our *count* state by calling the *increment* function.

```javascript
import { renderHook } from "@testing-library/react";
import { useCounter } from "./useCounter";

describe("useCounter", () => {
 test("Should increment the count", () => {
 const { result } = renderHook(useCounter);
 result.current.increment();
 expect(result.current.count).toBe(1);
 });
});
```
When you execute your tests, you will get an error kind of:
![Act utility missing error when updated state using RTL](https://i.imgur.com/KDmzC2W.png)
Act utility missing error when updating state using RTL

We’re getting this error because the component performs the *count* state change after the test has finished running. To solve this issue we have to use the React *Act* utility implemented by RTL. Actualy, when testing React components, everything that causes the state to update should go inside the “*act*”. Act will wait for state changes to settle and allow you to assert after.

Let’s update the state using *Act*:

```javascript
import { renderHook, act } from "@testing-library/react";
import { useCounter } from "./useCounter";

describe("useCounter", () => {
 test("should increment the count", () => {
 const { result } = renderHook(useCounter);
 act(() => result.current.increment()); //without using act() the count state will not be incremented
 expect(result.current.count).toBe(1);
 });

 test("should decrement the count", () => {
 const { result } = renderHook(useCounter);
 act(() => result.current.decrement()); //without using act() the count state will not be decremented
 expect(result.current.count).toBe(-1);
 });
});
```

### Next

Only practice can help you improve your knowledge and skills. Apply the knowledge gained in this tutorial in a concrete project. You can subscribe to [My Medium Account](https://medium.com/@mamadouniakate382) and also follow me on [twitter](https://twitter.com/mr_nkt223) and [github](https://github.com/mamadou-niakate) for new tutorials to come.

Testing React Custom Hooks with Jest and React Testing Library

In React applications, Providers are a way of helping share data between components which you can't easily share with props. They give access to data everywhere in the application to all the components they wrap. Thus, when testing these components, they must be tested in these Providers context. That’s exactly the subject of this post. We will learn how to test a single component and multiple components whitin a provider context.

## Let's first build our simple TODO app

In this post we will test a simple TODO app that uses React Context API for data management such as adding new task ou remove a task. Without wasting time, let's get down to business.

Lest’s create a new React App:

```bash
npx create-react-app testing-app-in-provider-context
```
— Copy paste the following code in the **App.css** file

```css
.App {
 display: flex;
 flex-direction: column;
 align-items: center;
 justify-content: center;
}

.container {
 display: flex;
 flex-direction: column;
 justify-content: flex-start;
 align-items: flex-end;
 max-width: 400px;
 padding: 10px;
}

.task-form > * {
 margin-left: 5px;
}

.task-list {
 display: flex;
 flex-direction: column;
 width: 100%;
}

.task {
 display: flex;
 justify-content: space-between;
 align-items: center;
 list-style: none;
}

.task :nth-child(1) {
 width: calc(100% / 2);
}

.task :nth-child(2) {
 width: calc(100% / 3);
}

.btn-add {
 background-color: #0bc886;
 color: #fff;
 border: none;
 border-radius: 5px;
 padding: 5px;
 cursor: pointer;
}

.btn-add:hover {
 background-color: #4dffbf;
}

.btn-delete {
 background-color: #ff0000;
 color: #fff;
 border: none;
 border-radius: 5px;
 padding: 4px;
 cursor: pointer;
}

.btn-delete:hover {
 background-color: #ff4d4d;
}
```
— Create **components**and **store** folders under the **src** folder the. Under the folder **components** folder create the files **tasksList.js** and **tasksListItem.js**. Inside the **store** folder, create the files **provider.js** and **reducer.js** files. That’s what we get as folder structure of the **src** folder.

```markdown
└── src/
 ├── components/
 │ ├── tasksListItem.js
 │ └── tasksList.js
 ├── store/
 | ├── provider.js
 | └── reducer.js
 ├── App.css
 ├── App.js
 ├── index.css
 ├── index.js
 ├── setupTests.js
 ├── package-lock.json
 └── package.json
```

You can remove all the others files.
— Now copy paste the following code in your **provider.js** file

```javascript
import { createContext, useContext, useReducer } from "react";
import { reducer } from "./reducer";

const Context = createContext();

const initialState = {
 tasks: [
 { id: 1, text: "Doctors Appointment", date: "09/01/2023" },
 { id: 2, text: "Meeting at School", date: "08/01/2023" },
 { id: 3, text: "Food Shopping", date: "10/01/2023" },
 ],
};

const ContextProvider = ({ children }) => {
 const [state, dispatch] = useReducer(reducer, initialState);
 return (
 <Context.Provider value={{ state, dispatch }}>{children}</Context.Provider>
 );
};

const useAppProvider = () => {
 const { state, dispatch } = useContext(Context);
 return { state, dispatch };
};

export { ContextProvider, useAppProvider };
```

Here, we just created a context provider with some initial data that we export using a custom hook.

— Update your **reducer.js** file with the following:
```javascript
export const reducer = (state, action) => {
 switch (action.type) {
 case "ADD_TASK":
 return {
 ...state,
 tasks: [...state.tasks, action.payload],
 };

 case "DELETE_TASK":
 return {
 ...state,
 tasks: state.tasks.filter((task) => task.id !== action.payload),
 };
 default:
 return state;
 }
};
```
Our reducer function will check our action type then perform some workround on the app global state content according to the action type such as removing a task or adding a new task.

Now our app context provider is ready for use, let’s wrap our app with it.

— Change the **App.js** content with the following code:

```javascript
import "./App.css";
import { ContextProvider } from "./store/provider";
import TasksList from "./components/tasksList";

function App() {
 return (
 <ContextProvider>
 <div className="App">
 <TasksList />
 </div>
 </ContextProvider>
 );
}

export default App;
```
Our App is wrapped by the Context provider making context based data available by all the components between the **\<ContextProvider>\</ContextProvider>** tags.

```javascript
import React, { useState } from "react";
import { useAppProvider } from "../store/provider";
import TasksListItem from "./tasksListItem";

function TasksList() {
 const { state: { tasks }, dispatch } = useAppProvider();

 const [text, setText] = useState("");

 const handleInputChange = (e) => {
 setText(e.target.value);
 };

 const handleAddTask = () => {
 if (!text) return;
 dispatch({
 type: "ADD_TASK",
 payload: {
 id: tasks.length + 1,
 text,
 date: new Date().toLocaleDateString(),
 },
 });
 setText("");
 };

 return (
 <div className="container">
 <h1>Task List</h1>
 <div className="task-form">
 <input
 type="text"
 placeholder="Add a task"
 value={text}
 onChange={handleInputChange}
 />
 <button className="btn-add" onClick={handleAddTask}>
 Add
 </button>
 </div>
 <ul className="task-list">
 {tasks.map((task) => (
 <TasksListItem key={task.id} task={task} />
 ))}
 </ul>
 </div>
 );
}

export default TasksList;
```
Here we used our costum hook **useAppProvider** to get access to the **global state** array of tasks and its modifier function **dispatch** that we use to add a new task.

— Last thing to do is to add the following lines of code to your **tasksListItem.js**
```javascript
import React from "react";
import { useAppProvider } from "../store/provider";

function TasksListItem({ task }) {
 const { id, text, date } = task;
 const { dispatch } = useAppProvider();

 const handleDelete = () => {
 dispatch({
 type: "DELETE_TASK",
 payload: id,
 });
 };

 return (
 <li className="task">
 {text}
 {date}
 <button className="btn-delete" onClick={handleDelete}>
 Delete
 </button>
 </li>
 );
}

export default Task;
```
You can now launch your app using the command 
```javascript
npm start
```
And voilà the results:

![testing the TODO app](https://i.imgur.com/NqrO77p.gif)

## Let’s tests our components
Before we start testing our component, let's first look at the blueprint of what we want to test. Now that you have your litle nice TODO application, here's our hook tesing plan:

- Render the **tasksList** component
- Render the **tasksListItem** component
- Check that the **tasksLists**t component render with 3 items

Before any test, create a **tasks.test.jsx** file under components folder. Then proceed as follows.

### ❌ Rendering the **tasksList** component in standalone way
The common mistake people do is rendering the component directly in the **render** method of React Testing Library without any other addinational configuration like follows:
```javascript
// tasks.test.jsx
import { render, screen } from '@testing-library/react';
import TasksList from './tasksList';

describe('TasksList', () => {
 test('renders tasks', () => {
 render(<TasksList/>);
 const tasksList = screen.getByRole('list')
 expect(tasksList).toBeInTheDocument();
 });
});
```
Oops ! something is wrong
![error using component outside context](https://i.imgur.com/xmKvmc8.png)
This approach does not work because in a real use case our component is inside a context so that it can give context value. So when testing, it should be tested also within the same context.
### ✅ Render the **tasksList** component inside text context
In order our component be tested inside the context and gives context value, the only thing we do is to add a second argument to the **render** method and assign our context provider to the **wrapper** property as follows.
```javascript
import { render, screen } from '@testing-library/react';
import { ContextProvider } from '../store/provider';
import TasksList from './tasksList';

describe('TasksList', () => {
 test('renders tasks', () => {
 render(<TasksList/>, { wrapper: ContextProvider });
 const tasksList = screen.getByRole('list') 
 expect(tasksList).toBeInTheDocument(); 
 });
});
```
Now any time you want to test another component needing the context, you must proceed as above. Here how we would test both **tasksList** and **tasksListItem** components.
```javascript
import { render, screen } from '@testing-library/react';
import { ContextProvider } from '../store/provider';
import TasksList from './tasksList';
import TasksListItem from './tasksListItem';

describe('TasksList and TasksListItem', () => {
 test('renders tasks', () => {
 render(<TasksList/>, { wrapper: ContextProvider });
 const tasksList = screen.getByRole('list') 
 expect(tasksList).toBeInTheDocument(); 
 });

 test('renders task item', () => {
 const task = { id: 1, title: 'test', date: '01-01-2023'};
 render(<TasksListItem task={task} />, { wrapper: ContextProvider });
 const taskItem = screen.getByRole('listitem') 
 expect(taskItem).toBeInTheDocument(); 
 });
});
```
Now you must ask that such long question: **Isn't there a way to indicate the context provider only once instead of indicating it for each component to be tested ?**

And the answer is: YES

### ✅ Custom Render Functions
React Testing Library allow you to create **your own render method** and indicate your context provider once instead of indicating for each fonction to be tested as follows :

— Under the **src** folder, create a new file named **test-utils.js** and copy paste in the following code:
```javascript
import { render } from "@testing-library/react";
import { ContextProvider } from "./store/provider";

const customRender = (ui, options) =>
 render(ui, { wrapper: ContextProvider, ...options });

export * from "@testing-library/react";
export { customRender as render };
```
Here our **customRender** takes the components we want to render (**ui**) and addition **options** and pass all of them to the React Testing Library **render** method. And we export all other React Testing Library methods and objects then we export our **customRender** renamed to **render**.

Now let’s test that:
```javascript
import { render, screen } from '../test-utils';
import TasksList from './tasksList';

describe('TasksList', () => {
 test('renders tasks', () => {
 render(<TasksList/>);
 const tasksList = screen.getByRole('list') 
 expect(tasksList).toBeInTheDocument(); 
 });
 
 test('Should tasks list render with 3 tasks', () => {
 render(<TasksList />)
 const tasksList = screen.getAllByRole('listitem')
 expect(tasksList).toHaveLength(3) 
 })
});
```
Voilà ! all's well That ends well.

**Source code**: [testing-context-provider-components](https://github.com/mamadou-niakate/tutorials/tree/testing-context-provider-components)

### Next

Only practice can help you improve your knowledge and skills. Apply the knowledge gained in this tutorial in a concrete project. You can subscribe to [to My Medium Account](https://medium.com/@mamadouniakate382) and also follow me on [twitter](https://twitter.com/mr_nkt223) and [github](https://github.com/mamadou-niakate) for new tutorials to come.

How to test React Components depending on the Context API

## What is Intersection Observer API
Intersection Observer is a JavaScript API for the Web that allows to observe the appearance of a target element in the browser document's viewpoint or in relation to one of its ancestors (one of elements that nests the target element).

## Some use cases of Intersection Observer
The good thing about Intersection Observer is that it does what you could only do by using several libraries before. You can use it for example for:
- Lazy-loading of images or other content as a page is scrolled.
- Implementing "infinite scrolling" web sites, where more and more content is loaded and rendered as you scroll, so that the user doesn't have to flip through pages.
- Reporting of visibility of advertisements in order to calculate ad revenues.
- Deciding whether or not to perform tasks or animation processes based on whether or not the user will see the result.

## Intersection observer concepts and usage
The Intersection Observer Interface provides a callback function that is called regarding to the following cases:
- The first time you tell the Observer to observe the target element
- When the target element crosses the document's viewpoint or a specific element. This specific element is called **root element** or **root**

In general, we look at the change in the intersection of the target element and the scrollable parent (ancestor) element closest to the target element. And if the target element has no scrollable parent, by default the document's viewpoint will be the reference.

> The degree of intersection between the target element and its root is the intersection ratio. This is a representation of the percentage of the target element which is visible as a value between 0.0 and 1.0.
>
> -- <cite>[MDN](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API#a_simple_example)</cite>

## Creating an intersection observer
```javascript
const options = {
	root: root_element,
	rootMargin: "",
	threshold: 1.0
}

let observer = new IntersectionObserver(callback, options)
```
The Intersection Observer takes two parameters:
- **Options**: The options allows the observer to control the execution of the callback function. It is an object with the following properties:

 - ***root***: The element (must be ancestor of the target element) used as viewpoint to check the visibility of the target element. If it is not specified or its value is ***null*** then the default viewpoint of the browser will be the reference.

 - ***rootMargin***: It is used the same way as the CSS margin property to define offsets added to each side of the intersection root's bounding box to create the final intersection root bounds.

 - **threshold**: It takes either a number or an array of numbers that indicates what percentage of the target element must be visible to execute the callback function. If we want to execute the callback function:
 - When 50% of the element is visible → threshold: 0.5
 - When each 25% of the element is visible → threshold: [0, 0.25, 0.5, 0.75, 1.0]

- **Callback function**: A function that will be run whenever a ***threshold*** is crossed. The function is called with two parameters:
 - An array of [IntersectionObserverEntry](https://developer.mozilla.org/en-US/docs/Web/API/IntersectionObserverEntry) objects. Each entry describes an intersection change for one observed element
 - The observer

## How to observe an element
Let's suppose we have a scrollable html element with ***id*** attribute equals to ***root*** and a nested element of that element with the ***id*** attribute equals to ****target****

Now let's see how to track the *target* element:

```javascript
const rootElem = document.querySelect("#root");
const targetElem = document.querySelect("#target");

const options = {
 root: rootElem,
 rootMargin: "0px",
 threshold: 0.5
}

const callback = (entries, observer) => {
 entries.forEach((entry) => {
 // target element:
 // entry.boundingClientRect
 // entry.intersectionRatio
 // entry.intersectionRect
 // entry.isIntersecting
 // entry.rootBounds
 // entry.target
 // entry.time
 });
};

const observer = new IntersectionObserver(callback, options)

observer.observe(targetElem)
```
What we do here is simple:
1. Select html elements
2. Define the root element
3. Define the visibility **threshold** of the target element from which to execute the callback function
4. Tell the observer to observe the target element visibility change

With the **threshold** value to **0.5** the *callback function* is only called when 50% of the target element is visible in the root element.

If the **threshold** value was an array like **[0, 0.25, 0.5, 0.75, 1]**, the *callback function* would be called when at least one pixel or 25% or 50% or 75% or 100% of the target element is visible in the root element.

And to check whether the target element is visible, we use the ***isIntersecting*** property of the entry object. It is a boolean that's **true** or **false** either the target element is intersecting with the root element or not.

## Let's practice

### Observe multiple target elements throught images lazy loading
The example here allows to load a random image from [picsum.photos](https://picsum.photos) and set it as the background image of the current list item in viewpoint. A loading text is diplayed during the loading time of the image. In this example, you will learn two (2) things:
- You will learn how to observe multiple target elements
- You will learn how to lazily load images

<iframe width="100%" height="700" src="//jsfiddle.net/ouwa_nkt/2m6z0nwp/80/embedded/js,html,css,result/dark/" allowfullscreen="allowfullscreen" allowpaymentrequest frameborder="0"></iframe>

As said previously, to tell the Intersection Observer to observe the target element intersection change with the browser document's viewpoint, you simply have to set the callback function option's **root** property to ***null*** or not to provide it at all.

### Create Infinite scroll
ou can watch the tutorial directly on youtube if you prefer visual content than reading.
<iframe width="100%" height="600" src="https://www.youtube.com/embed/wNMgrl4Budk" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

We have here a scrollable div element which **id** attribute value is ***scroller***. It is our **root** element. We also have a function called **loadCard** that creates **n** html elements and insert them into the scrollable div. Then we have our target element which **id** attribute value is ***target***.

Here to create the infinite scroll, i used a simple trick: The first time we observe the target element, the callback function is executed and as the page is blank, the target element will be forcely in the viewpoint and ***isIntersecting*** will be true. Next we add **10** elements to the scrollable div then we add the **target element** also to it. After that, each time we scroll to the target element, the previous steps will repeat and that creates an infinite scroll

<iframe width="100%" height="600" src="//jsfiddle.net/ouwa_nkt/es6qdnaz/11/embedded/js,html,css,result/dark/" allowfullscreen="allowfullscreen" allowpaymentrequest frameborder="0"></iframe>

Her you can notice that we didn't precise a value for **threshold**. It is because by default it's value is **0**. That means as soons as a single pixel of the target element is visible, the *callback function* will be executed

### Next Step
I hope you enjoyed reading this post and learned something from it. If yes, let's connect on [linkedin](https://www.linkedin.com/in/mamadou-niakate/). You can also follow me on [Twitter](itter.com/mr_nkt223) and [Github](https://github.com/mamadou-niakate) for more content. I publish also on [dev.to](https://dev.to/mamadouniakate) and [medium.com](https://medium.com/).

Thank you for your reading :)

How to use Intersection Observer API to create Infinite Scroll and Lazy-loading of images

## **Introduction**

As developers, we've all been tempted at one point or another by the allure of the * selector in SQL. It offers a quick and easy way to select all columns in a table, promising to simplify our SQL queries. However, this apparent convenience can come at a cost, leading to potential issues down the line. In this blog post, we'll explore why the use of the * selector should be limited.

## **Understanding the Basics of SQL and the * Selector**

SQL, or Structured Query Language, is a universal language for managing and manipulating databases. One of its key features is the ability to select specific columns from a database table. The * selector, acting as a shortcut for "all columns", might seem like an easy way to extract all data without the need to specify each column. However, its simplicity can be deceptive and lead to unintended consequences.

## **The Pitfalls of Over-relying on the * Selector**

### **⚠️ Performance Issues**

Consider you're working with a database for an e-commerce store, which has a 'Customers' table. This table might have dozens of columns and thousands of rows, storing everything from customer names to their purchase history. Using the * selector will return every single cell of data, which can place an unnecessary load on your database and your application:

```sql
SELECT * FROM Customers;
```

This query will return every column of data for every customer in the database, which can drastically slow down performance, particularly with large databases.

### **⚠️ Lack of Clarity and Control**

When we use the * selector, we lose some control over the data we're retrieving. It's also less clear for others who might be reading or maintaining our code. For instance, let's say you're working on a feature to display a list of customers. You might use the * selector like this:

```jsx
const sql = "SELECT * FROM Customers";
db.query(sql, function(err, result) {
  if (err) throw err;
  console.log(result);
});
```

In this Node.js code, we log all data from the 'Customers' table, but it's not immediately clear what that data will be.

### **⚠️ Potential Maintenance Issues with the * Selector**

For another example, let's imagine your 'Customers' table underwent some changes, and a few columns were renamed or reordered. If you've been using the * selector to retrieve all customer data, the returned columns might not match what your code expects:

```jsx
const sql = "SELECT * FROM Customers";
db.query(sql, function(err, result) {
  if (err) throw err;
  console.log(result[0].CustomerName, result[0].PhoneNumber); // What if 'PhoneNumber' was renamed or removed?
});
```

In this example, your code is dependent on 'CustomerName' and 'PhoneNumber' existing in the 'Customers' table. If 'PhoneNumber' is renamed or removed, this code will break, leading to potential bugs or crashes.

### **⚠️ Unintended Data Exposure**

An even more significant risk of using the * selector is that it can lead to unintended data exposure. When we use the * selector, we're asking the database to return every column in the table, which can potentially include sensitive information.

For instance, consider a 'Users' table with columns for 'username', 'email', and 'hashed_password'. Using the * selector in a query like this:

```javascript
const sql = "SELECT * FROM Users WHERE username = ${username}";
db.query(sql, function(err, result) {
  if (err) throw err;
  console.log(result);
});
```

In this code, all columns from the 'Users' table are retrieved, which may include the 'hashed_password' column. Exposing hashed passwords can be problematic, as attackers can attempt to reverse-engineer the original passwords.

To mitigate this risk, it's best to avoid using the * selector and explicitly specify the columns you need in your SQL queries. By doing so, you limit the retrieved data to only what is necessary, reducing the potential exposure of sensitive information.

For example, you can revise the code to select specific columns:

```javascript
const sql = `SELECT username, email FROM Users WHERE username = ${username}`;
db.query(sql, function(err, result) {
  if (err) throw err;
  console.log(result); // Only the 'username' and 'email' columns are retrieved
});
```

In this revised code, only the 'username' and 'email' columns are retrieved, keeping the 'hashed_password' securely stored in the database.

By explicitly specifying the columns, you have more control over the data being retrieved and minimize the risk of unintended exposure. It also makes your code more resilient to changes in the table schema since you only need to update the relevant queries when column names change.


## **✔️ Best Practices in Place of Using the * Selector**

The best way to avoid these issues is to explicitly specify the column names in your queries. This practice can improve performance, make your code clearer, and ensure it continues working even if the database schema changes. Here's how you can refactor the above code:

```jsx
const sql = "SELECT CustomerName, PhoneNumber FROM Customers";
db.query(sql, function(err, result) {
  if (err) throw err;
  console.log(result[0].CustomerName, result[0].PhoneNumber); // This will always retrieve 'CustomerName' and 'PhoneNumber'
});
```

In this example, even if other columns are added or removed, your code will continue to work as expected. As long as the 'CustomerName' and 'PhoneNumber' columns exist in the 'Customers' table, this code will correctly retrieve and log the customer names and phone numbers, making it a more reliable and maintainable solution.

## **Conclusion**

SQL's * selector is tempting to use for its convenience and simplicity. However, as we've seen throughout this article, relying on it can lead to performance degradation, decreased code clarity, increased maintenance overhead, and even security risks. These potential issues make a strong case for why we should think twice before using the * selector in our SQL queries.

Instead, we recommend explicitly stating the columns you need in your SQL queries. This approach offers several key benefits:

1. **Performance**: By only selecting the columns you need, you can reduce the load on your database and increase the speed of your queries.
2. **Clarity**: Explicitly stating the columns in your SQL queries makes your code more self-documenting, which is a great benefit for both you and any other developers who might work with your code in the future.
3. **Maintainability**: Your code becomes less prone to breakage due to changes in your database schema.
4. **Security**: By only selecting the data you need, you reduce the risk of exposing sensitive data.

Incorporating these best practices into your SQL queries takes little extra time but provides significant benefits in terms of performance, security, and maintainability. So, the next time you're about to use the * selector in SQL, stop and consider whether explicitly stating your column names might be a better, safer choice.

In the world of SQL, as with much of programming, clarity and precision are key. While the * selector may save a few keystrokes in the short term, the potential pitfalls and long-term maintenance issues make it a less desirable choice in many situations. Instead, strive to write SQL that is efficient, easy to understand, and resilient to changes – your future self, your users, and your fellow developers will thank you!

How to manage file storage using GridFS with Node.js/Express js, Mongodb, Mongoose and Multer ?

Testing React Custom Hooks with Jest and React Testing Library

How to test React Components depending on the Context API

How to use Intersection Observer API to create Infinite Scroll and Lazy-loading of images

Why You Shouldn't Overuse the * Selector in SQL

Mamadou Niakaté

Categories

Social