Forem: Zahid Hasan

Chatgpt Google Chrome Extension

Zahid Hasan — Sun, 12 Feb 2023 15:13:21 +0000

I made a simple chatgpt extension for Chrome! The extension scrolls to your question when you click its number. It's an open-source project. Check out the demo and feel free to try it out for yourself.

Github Link: https://github.com/ZahidHasan24/chatgpt-scroll-chrome-extension

Interface Segregation Principle in React

Zahid Hasan — Sat, 21 Jan 2023 18:25:11 +0000

What is the Single Responsibility Principle?

The Interface Segregation Principle (ISP) is an oop principle that states that clients (objects or classes) should not be required to implement interfaces (or methods) that they do not utilize. In other words, it is a philosophy that favors smaller, more particular interfaces over larger, more broad ones. This contributes to reducing system complexity by making it more modular and easier to comprehend and maintain.

Consider the Toy interface, which offers numerous methods such as play(), stop(), and break() (). Assume we have two kinds of toys: a vehicle toy and a doll toy. The play() and stop() methods are sufficient for the vehicle toy, while the play() and break() methods are required for the doll toy.

If we do not adhere to the ISP, the Toy interface would have all three methods (play(), stop(), and break()), and both the vehicle toy and the doll toy would be required to implement all three methods, even though the doll toy will never utilize the stop() method.

We would construct two new interfaces, VeichleToy and DollToy, in accordance with the ISP. The VeichleToy interface would only have the play() and stop() methods, whereas the DollToy interface would only have the break() and play() methods. In this manner, the vehicle toy can implement the VeichleToy interface and the doll toy can implement the DollToy interface without implementing extra methods.

We have thereby decreased the system’s complexity while increasing its maintainability.

How can you implement ISP in React?

In React, you can implement the Interface Segregation Principle using hooks or Higher-Order Components (HOC), or Render Props.

In this article, we will use hooks to learn about this.

Here’s an example of how the ISP can be violated when using React hooks:

Assume you have a UserProfile component that displays a user’s information such as their name, email, and profile image. The component utilizes the useEffect hook to contact an API and set the user’s data in the component’s state in order to retrieve the user’s data.

Suppose you have a component named UserSettings that similarly needs to get the user’s data, but this time it needs to update the user’s data by accessing another API.

You might be tempted to reuse the UserProfile component’s code to retrieve the user’s data in this scenario. However, you are breaking the ISP by doing so because the UserProfile component simply needs to fetch data, whereas the UserSettings component needs to fetch and alter data.

Here’s the code that violates the ISP:

import { useEffect, useState } from 'react';

const UserProfile = () => {
  const [userData, setUserData] = useState({});

  useEffect(() => {
    const fetchUserData = async () => {
      const response = await fetch('/api/user');
      const data = await response.json();
      setUserData(data);
    }
    fetchUserData();
  }, []);

  return <div>{userData.name}</div>;
}

const UserSettings = () => {
  const [userData, setUserData] = useState({});

  useEffect(() => {
    const fetchUserData = async () => {
      const response = await fetch('/api/user');
      const data = await response.json();
      setUserData(data);
    }
    fetchUserData();
  }, []);

  const updateUserData = async () => {
    await fetch('/api/user', {
      method: 'PATCH',
      body: JSON.stringify(userData),
    });
  }

  return (
    <div>
      <input
        value={userData.name}
        onChange={(e) => setUserData({ ...userData, name: e.target.value })}
      />
      <button onClick={updateUserData}>Save</button>
    </div>
  );
}

You may solve this issue by creating two different hooks: one for getting data and one for changing data. Then, in each component, you may use the relevant hook.

For example, you might construct a hook named useFetchUserData that just deals with getting the user’s data and another called useUpdateUserData that only deals with updating the user’s data. The useFetchUserData hook may be used by the UserProfile component, while the useUpdateUserData hook can be used by the UserSettings component.

Because each component only implements the methods it requires, and the hooks are short and have particular interfaces, you are complying with the ISP.

Here’s the refactored code:

import { useEffect, useState } from 'react';

const useFetchUserData = () => {
  const [userData, setUserData] = useState({});

  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch('/api/user');
      const data = await response.json();
      setUserData(data);
    }
    fetchData();
  }, []);

  return userData;
}

const useUpdateUserData = () => {
  const [userData, setUserData] = useState({});

  const updateData = async () => {
    await fetch('/api/user', {
      method: 'PATCH',
      body: JSON.stringify(userData),
    });
  }

  return { userData, setUserData, updateData };
}

const UserProfile = () => {
  const userData = useFetchUserData();
  return <div>{userData.name}</div>;
}

const UserSettings = () => {
  const { userData, setUserData, updateData } = useUpdateUserData();
  return (
    <div>
      <input
        value={userData.name}
        onChange={(e) => setUserData({ ...userData, name: e.target.value })}
      />
      <button onClick={updateData}>Save</button>
    </div>
  );
}

Liskov Substitution Principle in React

Zahid Hasan — Fri, 13 Jan 2023 15:47:29 +0000

What is Liskov Substitution Principle?

The Liskov Substitution Principle (LSP) is a guideline that assists in the effective functioning of the software. It states that if something is of a given kind, you should be able to substitute a different but similar item for it and the software would still function properly.

Consider a toy box filled with various sorts of toys such as vehicles, dolls, and balls. Because the toy box can only contain toys, whatever is placed within it must be a toy. According to the LSP, if you have a toy car, you should be able to replace it with a toy truck and the toy box should still function properly.

According to the LSP, objects of a superclass should be able to be substituted by objects of a subclass without impacting the program’s correctness.

How can you implement Liskov Substitution Principle in React?

Here are some ways to implement the Liskov Substitution Principle in React:

Make your own hooks to specify the anticipated behavior and features of certain functionality, such as a form input. Any component that makes use of the custom hook should be able to be utilized whenever a form input is anticipated and the application should still function properly.
Create custom hooks that expect a set of properties, such as an object containing the component’s state and behavior, then return the desired behavior and properties. As long as the items have the same form, this enables for easy substitution of various objects with varying actions.
Use composition to define the expected behavior and properties of a component. Composing small and focused components together, it allows for easy substitution of related components that conform to the same interface and behavior.

Here’s an example of a scenario where the Liskov Substitution Principle is violated:

Assume you have a custom hook named useAuth that controls an application’s authentication state, such as the user’s token and login status.

import { useState } from "react";

const useAuth = () => {
  const [token, setToken] = useState(null);
  const [isLoggedIn, setIsLoggedIn] = useState(false);

  const login = (token) => {
    setToken(token);
    setIsLoggedIn(true);
  }

  const logout = () => {
    setToken(null);
    setIsLoggedIn(false);
  }

  return { token, isLoggedIn, login, logout };
}

Suppose you have a component named Profile that renders the user’s information while they are signed in and a login button when they are not.

const Profile = () => {
  const { token, isLoggedIn, login } = useAuth();

  if (!isLoggedIn) return <button onClick={() => login("pass")}>Login</button>;

  return <p>Welcome, you are logged in.</p>;
}

Imagine you want to add another component named Settings that allows the user to update their settings while they are logged in and a login button when they are not.

const Settings = () => {
  const { token, isLoggedIn, login } = useAuth();

  if (!isLoggedIn) return <button onClick={() => login("pass")}>Login</button>;

  return (
    <div>
      <form>
        <label>Change your password</label>
        <input type="password" placeholder="New password" />
        <button>Save</button>
      </form>
    </div>
  );
}

As you can see, both the Profile and Settings components utilize the useAuth hook to manage the application’s authentication state, but because each component has distinct expectations for the hook, the useAuth hook is unable to handle the various cases. Because the useAuth hook cannot be used interchangeably in various components, this violates the LSP.

To address this issue, you could construct different hooks for different use cases, or you could develop a more general hook that can handle multiple circumstances by giving more parameters such as anticipated behavior or data.

Following this principle allows you to design a collection of interchangeable hooks, which makes it simple to add new features to your application because you can use the same hooks for other components and the application will still function appropriately.

Here is one solution to fix the issue of the useAuth hook violating the LSP:

Create a more general useAuth hook that can handle several cases by giving additional arguments, such as desired behavior or data.

import { useState } from "react";

const useAuth = (initialAuth) =>{
  const [auth, setAuth] = useState(initialAuth);

  const login = (token) => {
    setAuth({ token, isLoggedIn: true });
  }

  const logout = () => {
    setAuth({ token: null, isLoggedIn: false });
  }

  return { auth, login, logout };
}

Pass the initial auth state as a parameter to the useAuth hook.

const Profile = () => {
  const { auth, login } = useAuth({ token: null, isLoggedIn: false });

  if (!auth.isLoggedIn)
    return <button onClick={() => login("pass")}>Login</button>;

  return <p>Welcome, you are logged in.</p>;
};

const Settings = () => {
  const { auth, login } = useAuth({ token: null, isLoggedIn: false });

  if (!auth.isLoggedIn)
    return <button onClick={() => login("pass")}>Login</button>;

  return (
    <div>
      <form>
        <label>Change your password</label>
        <input type="password" placeholder="New password" />
        <button>Save</button>
      </form>
    </div>
  );
};

The useAuth hook may handle multiple scenarios and be used interchangeably in other components by giving the initial auth state as a parameter. This enables the components to have varied expectations for the hook while still functioning appropriately, in accordance with the Liskov Substitution Principle.

Open-Closed Principle In React

Zahid Hasan — Wed, 04 Jan 2023 18:57:18 +0000

What is the Open-Closed Principle?

The Open Close Principle is a software design principle that stated that software entities (classes, modules, functions, etc.) should be extensible but not modifiable.

This means that you should be able to add new functionality to an existing software entity without modifying its code.

Assume you have a toy box filled with a variety of toys. The toy box functions similarly to a software entity. You may continue to add new toys to the toy box (expand it) without changing the toy box itself. However, you should not have to open the toy box and change its structure or construction every time you want to add a new toy (modifying it).

How can you implement OCP in React?

One way to implement the Open Close Principle in React is to use higher-order components (HOCs).

Functions that accept a component as an input and return a new component are examples of higher-order components. HOCs may be used to extend the functionality of a component without modifying its code.

Here’s an example of a React component that violates the Open-Closed Principle:

import React, { useState, useEffect } from 'react';
import axios from 'axios';

function UserList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    async function fetchData() {
      setLoading(true);
      try {
        const response = await axios.get('/api/users');
        setUsers(response.data);
      } catch (err) {
        setError(err);
      }
      setLoading(false);
    }
    fetchData();
  }, []);

  if (loading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>Error: {error.message}</p>;
  }

  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

This component displays a list of users fetched through an API call. It is divided into three states: loading, error, and users. When the component mounts, it retrieves data from the API and shows a loading spinner or an error message if there is a problem.

The issue with this solution is that the component is not extensible. If you want to add new functionality to the component, such as filtering the list of users by name, you must change the code. To incorporate the filter in the API request, you would need to add a new state variable for it and edit the useEffect hook.

To solve this while following the Open Closed Principle, you may divide the API functionality and state management into a distinct custom hook that can be readily extended without rewriting its code.

Here is the refactored version of the UserList the component that follows the Open Close Principle:

import React from 'react';
import useApi from './useApi';

function UserList() {
  const { data: users, loading, error } = useApi('/api/users');

  if (loading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>Error: {error.message}</p>;
  }

  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

The useApi the hook is a custom hook that manages API logic and state. It accepts a URL as an input and produces an object containing the data, loading, and error states.

The useApi a hook is implemented as follows:

import { useState, useEffect } from 'react';
import axios from 'axios';

function useApi(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    async function fetchData() {
      setLoading(true);
      try {
        const response = await axios.get(url);
        setData(response.data);
      } catch (err) {
        setError(err);
      }
      setLoading(false);
    }
    fetchData();
  }, [url]);

  return { data, loading, error };
}

export default useApi;

You can now simply add new features to the UserList component without having to modify its code. For example, you may use the useApi hook to add a filter to the list of users, as seen below:

import React from 'react';
import useApi from './useApi';

function UserList() {
  const [filter, setFilter] = useState('');
  const { data: users, loading, error } = useApi(`/api/users?name=${filter}`);

  if (loading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>Error: {error.message}</p>;
  }

  return (
    <>
      <input type="text" value={filter} onChange={event => setFilter(event.target.value)} />
      <ul>
        {users.map(user => (
          <li key={user.id}>{user.name}</li>
        ))}
      </ul>
    </>
  );
}

The UserList a component is now extendable, allowing you to add new features without modifying the code.

Single Responsibility Principle in React

Zahid Hasan — Thu, 29 Dec 2022 10:19:32 +0000

What is the Single Responsibility Principle?

The Single Responsibility Principle (SRP) is a software design principle that asserts a software module or component should only change for one cause. In other words, a class or function should only have one clear duty or job. Following this idea might assist in making your code more manageable and understandable.

How can you implement SRP in React?

The SRP may be implemented in React by ensuring that each component in your application serves a single, well-defined purpose. A component, for example, maybe in charge of displaying a specific section of the UI, processing user input, or performing API calls to retrieve data. You may make your code easier to comprehend and maintain by restricting a component’s duties to a single, well-defined job.

Here are a few points for applying the SRP in a React application:

Keep your components small and focused: As far as possible, keep your components small and focused, with each component having a single, well-defined task.
Avoid mixing concerns: Avoid combining unrelated problems in a single component. A component responsible for displaying a form, for example, should not simultaneously be responsible for performing API calls to get data.
Use composition: Composition is a technique for combining fewer, more concentrated components into bigger, more complicated components. This might assist in making your code modular and understandable.
Use props and state appropriately: Props may be used to transmit data and behavior down to child components, while the state can be used to maintain the local state within a component. Use state to handle data that is not exclusive to a single component.

Here’s an example of a React component that violates the Single Responsibility Principle:

import React, { useState } from 'react';
import { ApiService } from './Service/Api';

// This component has multiple, unrelated responsibilities:
// rendering a form, making API calls, and displaying a 
// loading spinner.
function AddItemForm() {
  const [item, setItem] = useState('');
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState(null);

  const handleChange = (event) => {
    setItem(event.target.value);
  }

  const handleSubmit = async (event) => {
    event.preventDefault();
    setIsLoading(true);
    try {
      await ApiService.SendItem({item})
      setIsLoading(false);
    } catch (error) {
      setIsLoading(false);
      setError(error);
    }
  }

  return (
    <div>
      { isLoading && <div>Loading...</div> }
      { error && <div>{error.message}</div> }
      <form onSubmit={handleSubmit}>
        <label>
          Add Item:
          <input type="text" value={item} onChange={handleChange} />
        </label>
        <button type="submit">Add</button>
      </form>
    </div>
  );
}

export default AddItemForm;

This component is responsible for a variety of unconnected tasks, including rendering a form, making API calls to add a new item to the list, and showing a loading spinner and error warnings. These tasks are unrelated and may vary for a variety of reasons, which contradicts the Single Responsibility Principle.

To make this component more manageable and understandable, these tasks should be separated into independent components. You could, for example, design a separate component to handle API requests and another to display the loading spinner and error warnings. This would make the code easier to comprehend as well as test and maintain.

You might divide the tasks of producing a form, executing API calls, and showing a loading spinner and error messages into multiple components to make the AddItemForm component comply with the Single Responsibility Principle. Here’s an example of refactoring the component:

import React, { useState } from 'react';
import LoadingSpinner from './LoadingSpinner';
import ErrorMessage from './ErrorMessage';
import AddItemForm from './AddItemFrom.js'
import { ApiService } from './Service/Api';

// This component has a single, well-defined responsibility:
// making API calls to add a new item to the list.
function AddItemFormContainer() {
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState(null);

  const addItem = async (item) => {
    setIsLoading(true);
    try {
      await ApiService.SendItem({item})
      setIsLoading(false);
    } catch (error) {
      setIsLoading(false);
      setError(error);
    }
  }

  return (
    <div>
      { isLoading && <LoadingSpinner /> }
      { error && <ErrorMessage error={error} /> }
      <AddItemForm addItem={addItem} />
    </div>
  );
}

export default AddItemFormContainer;

import React, { useState } from 'react';

// This component has a single, well-defined responsibility:
// rendering a form to add a new item to a list.
function AddItemForm(props) {
  const [item, setItem] = useState('');

  const handleChange = (event) => {
    setItem(event.target.value);
  }

  const handleSubmit = (event) => {
    event.preventDefault();
    props.addItem(item);
    setItem('');
  }

  return (
    <form onSubmit={handleSubmit}>
      <label>
        Add Item:
        <input type="text" value={item} onChange={handleChange} />
      </label>
      <button type="submit">Add</button>
    </form>
  );
}

export default AddItemForm;

The useState hook is used to handle the local state within the AddItemForm and AddItemFormContainer components in this version. The AddItemForm component has one state variable, item, while the AddItemFormContainer component has two, isLoading and error. The useState hook is used to initialize these state variables and the accompanying update functions, which are used to store and update the values of the loading spinner and error message.

The components are simple to comprehend and manage because they adhere to the Single Responsibility Principle and confine the responsibility of these components to a single, well-defined activity.

What are the good ways to avoid bugs?

Zahid Hasan — Sun, 01 Nov 2020 16:06:09 +0000

I have been working as a web developer almost 3 years. Now a days build ui and functionality with react redux. But I am facing a problem that is I am finding bugs with others code but some bugs are avoided by my eyes. Its happening all the times now a days. And its really ashamed for me to raise this kind of issues severally. What are the best ways to resolve this? Hope some professional seniors will see this post and give me an advice.