Forem: Ibukunoluwa Popoola

React Custom Hooks: Crafting Reusable and Clean Code Like a Pro

Ibukunoluwa Popoola — Fri, 02 Aug 2024 12:01:15 +0000

In the world of React, hooks have revolutionized how we manage state and side effects in functional components. However, as applications become complex, we often find ourselves repeating logic across different components. This is where custom hooks come in handy. Custom hooks allow us to extract reusable logic, making our components cleaner and more maintainable.

In this post, we'll explore how to create custom hooks and demonstrate a real-world example that enhances code reusability and abstraction. To get the most out of this post, it's beneficial if you're already familiar with the basics of React, including functional components, the use of built-in hooks like useState and useEffect, and fundamental JavaScript concepts such as Promises and asynchronous operations. If you're comfortable with these concepts, you'll find it easier to follow along and implement custom hooks in your projects.

Custom hooks enable you to:

Encapsulate Logic: Separate logic from UI components, making code more modular and easier to manage.
Reuse Logic: Share common logic across multiple components, reducing duplication.
Simplify Components: Keep components focused on rendering UI by offloading business logic to hooks.

Creating a Custom Hook: A Practical Example

Let's consider a common use case: fetching and managing data from an API. We'll create a custom hook, useFetch, that handles data fetching, loading states, and errors.

Step 1: Setup the Basic Hook Structure

import { useState, useEffect } from 'react';

const useFetch = (url) => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      setLoading(true);
      try {
        const response = await fetch(url);
        if (!response.ok) {
          throw new Error('Network response was not ok');
        }
        const result = await response.json();
        setData(result);
      } catch (error) {
        setError(error.message);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, [url]);

  return { data, loading, error };
};

export default useFetch;

Step 2: Using the Custom Hook in a Component

Now that we have our custom useFetch hook, let's use it in a component.

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

const UserList = () => {
  const { data: users, loading, error } = useFetch('https://jsonplaceholder.typicode.com/users');

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

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

export default UserList;

Step 3: Enhancing the Custom Hook

To make our useFetch hook more versatile, we'll add a feature that allows re-fetching data on demand. This can be useful in scenarios where you need to refresh the data in response to user actions or other events.

To achieve this, we will refactor the fetchData function out of the useEffect hook and wrap it in a useCallback hook. This approach serves two purposes:

Reusability: By extracting fetchData, we can call it directly from components using the hook, allowing us to re-fetch data as needed.
Memory Optimization: Wrapping fetchData in useCallback ensures that the function instance remains stable across re-renders unless the dependencies change. This prevents unnecessary re-creation of the function, which can help optimize memory usage and reduce the chances of re-triggering the effect unintentionally.

Here’s the updated implementation:

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

const useFetch = (url) => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  const fetchData = useCallback(async (abortController) => {
    setLoading(true);
    try {
      const response = await fetch(url, {
        signal: abortController.signal
      });
      if (!response.ok) {
        throw new Error('Network response was not ok');
      }
      const result = await response.json();
      setData(result);
    } catch (error) {
      if (error.name === 'AbortError') {
        console.log('Request was cancelled');
      } else {
        setError(error.message);
      }
    } finally {
      setLoading(false);
    }
  }, [url]);

  useEffect(() => {
    // AbortController is used to abort ongoing fetch requests when the component unmounts or the URL changes
    const abortController = new AbortController();

    fetchData(abortController);

    // Cleanup function to cancel the request when the component unmounts or the URL changes
    return () => {
      abortController.abort();
    };
  }, [fetchData]);

  return { data, loading, error, refetch: fetchData };
};

export default useFetch;

Now, the useFetch hook provides a refetch function that can be called to re-fetch the data.

Other Use Cases Where Custom Hooks Are Ideal

Here are 3 other common use cases where custom hooks can be particularly beneficial:

useLocalStorage: Managing state that persists across sessions can be challenging. The useLocalStorage custom hook can simplify this by abstracting the logic for storing and retrieving values from the localStorage API. It provides a way to keep the component state in sync with local storage, ensuring that data is saved even if the user closes or refreshes the browser.

Example Implementation:

// https://usehooks.com/useLocalStorage
import { useState } from 'react';

// Hook
function useLocalStorage(key, initialValue) {
  // State to store our value
  // Pass initial state function to useState so logic is only executed once
  const [storedValue, setStoredValue] = useState(() => {
    if (typeof window === 'undefined') {
      return initialValue;
    }

    try {
      // Get from local storage by key
      const item = window.localStorage.getItem(key);
      // Parse stored JSON or if none return initialValue
      return item ? JSON.parse(item) : initialValue;
    } catch (error) {
      // If error also return initialValue
      console.log(error);
      return initialValue;
    }
  });

  // Return a wrapped version of useState's setter function that ...
  // ... persists the new value to localStorage.
  const setValue = (value) => {
    try {
      // Allow value to be a function so we have the same API as useState
      const valueToStore = value instanceof Function ? value(storedValue) : value;
      // Save state
      setStoredValue(valueToStore);
      // Save to local storage
      if (typeof window !== 'undefined') {
        window.localStorage.setItem(key, JSON.stringify(valueToStore));
      }
    } catch (error) {
      // A more advanced implementation would handle the error case
      console.log(error);
    }
  };

  return [storedValue, setValue];
}

useWindowSize: Handling responsive design often requires tracking the window size to adjust layouts or elements dynamically. The useWindowSize hook abstracts the logic for detecting and reacting to window resize events, making it easy to implement responsive UI elements.

Example Implementation:

import { useState, useEffect } from 'react';

const useWindowSize = () => {
  const [size, setSize] = useState({
    width: window.innerWidth,
    height: window.innerHeight,
  });

  useEffect(() => {
    const handleResize = () => {
      setSize({
        width: window.innerWidth,
        height: window.innerHeight,
      });
    };
    window.addEventListener('resize', handleResize);
    return () => window.removeEventListener('resize', handleResize);
  }, []);

  return size;
};

useDebounce: The useDebounce hook is useful for delaying the execution of a function after a certain period, typically to avoid calling an expensive operation multiple times in quick succession. This is particularly useful for handling search inputs, where you want to wait until the user stops typing before making an API call.

Example Implementation:

import { useState, useEffect } from 'react';

const useDebounce = (value, delay) => {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const handler = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    return () => {
      clearTimeout(handler);
    };
  }, [value, delay]);

  return debouncedValue;
};

// Use in a component
import { useDebounce } from './useDebounce';

const SearchComponent = () => {
   const [searchTerm, setSearchTerm] = useState('')
   const debouncedSearchTerm = useDebounce(searchTerm, 500)  // Will only trigger API call 500ms after user stops typing!

   useEffect(() => {
      if(debouncedSearchTerm) {
         // Make API call!
      }
   }, [debouncedSearchTerm])

   return <input onChange={e => setSearchTerm(e.target.value)} />
}

Each of these custom hooks addresses a specific problem and can significantly simplify your code by abstracting common logic into reusable components. This not only reduces duplication but also enhances the clarity and maintainability of your React applications.

Best Practices for Custom Hooks

Use the use prefix: Ensure your custom hook's name starts with use to follow React's conventions and enable the hook rules.
Keep hooks focused: Custom hooks should do one thing well. Avoid overloading them with too much logic.
Handle cleanup: Use the useEffect cleanup function to handle any necessary cleanup operations, like cancelling network requests.

Conclusion

Custom hooks are a powerful tool in React that can help you write cleaner, more maintainable code. By encapsulating logic into reusable hooks, you can keep your components focused on rendering UI and improve your application's scalability.

Feel free to use and extend the hooks outlined above, and try creating custom hooks in your next project, and see how they can simplify your codebase! Check out useHooks for many other useful hooks. Make sure to keep an eye out on React 19 as well. The 2024 conference happened recently and the new hooks are off the hook. Till next time, useTime...

The Art of Reusability: Generics in TypeScript and React

Ibukunoluwa Popoola — Tue, 09 Jul 2024 15:45:47 +0000

As frontend developers, we're no strangers to the concept of reusability. We strive to write code that's modular, flexible, and easy to maintain. But when it comes to working with different data types, we often find ourselves writing duplicate code or resorting to any types, sacrificing type safety in the process.

In React, we're familiar with the concept of components as functions that take in props and return JSX elements. But what if we want to create a component that can work with different types of data, such as strings, numbers, or custom objects? How can we ensure that our component is type-safe and flexible enough to accommodate different data types?

This is where generics come in – a powerful feature in TypeScript that allows us to write reusable, type-safe code. By using generics, we can create components that can work with multiple data types, without sacrificing type safety or flexibility.

In this post, we'll explore the world of generics in TypeScript, using real-world React components to illustrate and explain. We'll start with a simple example of a generic container component, and then move on to more complex examples, such as a generic list component. By the end of this post, you'll have a solid understanding of how to use generics to write more reusable, maintainable, and type-safe code in your React applications.

What are Generics?
Generics are a way to create reusable functions, classes, and interfaces that can work with multiple data types while maintaining type safety. They allow you to specify a type parameter that can be replaced with a specific type when the generic is instantiated.

Think of generics like a blueprint or a template. You define a generic function or class with a type parameter, and then you can use that generic with different types, just like how you would use a blueprint to build different houses.

A Simple Example: A Generic Container Component
Let's create a simple React component that demonstrates the power of generics. Imagine we want to create a container component that can render any type of data. We can use a generic to achieve this:

interface ContainerProps<T> {
  data: T;
}

const Container = ({ data }: ContainerProps<any>) => {
  return <div>{JSON.stringify(data)}</div>;
};

In this example, we define an interface ContainerProps with a type parameter T. This interface has a single property data of type T. We then create a React component Container that uses this interface as its props type.

Notice the any type passed to the ContainerProps interface. This tells TypeScript that we want to allow any type for the T parameter. However, this can lead to type safety issues, so let's improve this example.

Improving Type Safety with Generics
Instead of using any, we can specify the type parameter when we use the Container component:

interface ContainerProps<T> {
  data: T;
}

const Container = <T,>({ data }: ContainerProps<T>) => {
  return <div>{JSON.stringify(data)}</div>;
};

// Using the Container component with a string type
const StringContainer = () => {
  return <Container<string> data="Hello, World!" />;
};

// Using the Container component with a number type
const NumberContainer = () => {
  return <Container<number> data={42} />;
};

Now, we've improved the type safety of our Container component. When we use the component, we specify the type parameter, which ensures that the data property has the correct type. For instance, for the StringContainer component, if we try passing a number value or a value of any other type e.g. an object, we get an error from Typescript informing us of the type mismatch. Ditto for the NumberContainer component.

A More Complex Example: A Generic List Component

Let's create a more complex React component that demonstrates the power of generics. Imagine creating a list component that can render a list of any type of data. We can use a generic to achieve this:

interface ListProps<T> {
  items: T[];
  renderItem: (item: T) => JSX.Element;
}

const List = <T,>({ items, renderItem }: ListProps<T>) => {
  return (
    <ul>
      {items.map((item, index) => (
        <li key={index}>{renderItem(item)}</li>
      ))}
    </ul>
  );
};

// Using the List component with a string type
const StringList = () => {
  return (
    <List<string>
      items={['Apple', 'Banana', 'Cherry']}
      renderItem={(item) => <span>{item}</span>}
    />
  );
};

// Using the List component with a custom type
interface Person {
  name: string;
  age: number;
}

const PersonList = () => {
  return (
    <List<Person>
      items={[
        { name: 'John', age: 30 },
        { name: 'Jane', age: 25 },
      ]}
      renderItem={(person) => (
        <span>
          {person.name} ({person.age})
        </span>
      )}
    />
  );
};

In this example, we define a List component that takes a type parameter T. The component has two props: items which is an array of type T, and renderItem which is a function that takes an item of type T and returns a JSX element.

We then use the List component with different types: string and a custom Person type. The renderItem function is specific to each type, ensuring that the component is type-safe and flexible.

Conclusion
Generics is a powerful feature in TypeScript that allows you to write reusable, type-safe code. By using real-world React components, we've demonstrated how generics can help you create flexible and maintainable code.

Remember, generics are like blueprints or templates that can be used with different types. By specifying type parameters, you can ensure type safety and flexibility in your code.

I hope this post has triggered your interest in generics in TypeScript and inspired you to write more reusable and maintainable code. Happy coding!

Useful Links

https://www.typescriptlang.org/docs/handbook/2/generics.html

Type-Safe React: Harnessing the Power of Discriminated Unions

Ibukunoluwa Popoola — Sun, 26 May 2024 14:01:46 +0000

As front-end developers, we've all been there - in a situation where we want to pass a prop to a child component, but only if another prop is present. It's a common situation that can lead to messy, hard-to-maintain code. But fear not, dear reader, for there's a solution that can simplify your code and make it more type-safe: discriminated unions.

Conditional Props

Imagine you're building a Button component that can be either a primary or secondary button. You want to pass a label prop to the component, but only if the variant prop is set to "primary". If variant is "secondary", you don't want to pass the label prop.

interface ButtonProps {
  variant: 'primary' | 'secondary';
  label?: string;
}

const Button = ({ variant, label }: ButtonProps & React.ButtonHTMLAttributes<HTMLButtonElement>) => {
  return <button {...props}>{variant === 'primary' ? label : ''}</button>;
};

This implementation has some issues:

The label prop is optional, which can lead to undefined errors if it's not provided when variant is "primary".
The component has to perform runtime checks to ensure the label prop is present when variant is "primary".

Enter Discriminated Unions:

Discriminated unions, also known as tagged unions, are a powerful feature in TypeScript that can help us solve this problem. A discriminated union is a type that can be one of several types, depending on the value of a specific property, called the discriminant.

Let's redefine our ButtonProps interface using a discriminated union:

interface PrimaryButtonProps {
  variant: 'primary';
  label: string;
}

interface SecondaryButtonProps {
  variant: 'secondary';
}

type ButtonProps = PrimaryButtonProps | SecondaryButtonProps;

Here, we've defined two separate interfaces: PrimaryButtonProps and SecondaryButtonProps. By defining ButtonProps as a union type, we're saying that a ButtonProps object can have either the shape of a PrimaryButtonProps object or a SecondaryButtonProps object depending on the variant property, which is the discriminant. It is important to note that whatever is used as the discriminant is required for all separate interfaces when applying the concept of discriminated unions. So if we had a third button variant, say "tertiary", the interface TertiaryButtonProps must include the variant prop.

interface PrimaryButtonProps {
  variant: 'primary';
  label: string;
}

interface SecondaryButtonProps {
  variant: 'secondary';
}

// Wrong Implementation
interface TertiaryButtonProps {
  // missing required `variant` prop
  tertiaryProp?: any;
}

// Correct Implementation
interface TertiaryButtonProps {
  variant: 'tertiary'; // Required prop
  tertiaryProp?: any;
}

type ButtonProps = PrimaryButtonProps | SecondaryButtonProps | TertiaryButtonProps;

Now, let's update our Button component to use this new ButtonProps type:

const Button = (props: ButtonProps & React.ButtonHTMLAttributes<HTMLButtonElement>) => {
  const { variant } = props; 
  return <button {...props}>{variant === 'primary' ? props.label : 'Secondary Button'}</button>;
};

With this implementation, TypeScript will ensure that when variant is primary, the label prop is always present. If variant is secondary, the label prop is absent. The discriminated union has helped us handle a conditional prop that depends on the value of another prop.

Here are some other common use cases for discriminated unions in React development:

Form Validation: When building forms, we often need to validate user input based on the type of input field. Discriminated unions can help us define separate validation rules for different input types.
Modals: When building modals, we might want to pass different props depending on the type of modal (e.g. error modal, success modal, etc.).
Accordion Components: Accordion components often require different props depending on whether the accordion item is expanded or collapsed.
Responsive Design: We might want to pass different props to a component based on the screen size or device type when building responsive designs.

So, what makes discriminated unions so useful?

Type Safety: Discriminated unions ensure that the type of the props object is correctly inferred based on the value of the discriminant property.
Code Clarity: By defining separate interfaces for each possible type, our code becomes more readable and easier to understand.
Fewer Runtime Checks: With discriminated unions, we can eliminate runtime checks and ensure that our code is correct at compile time.

Conclusion

Discriminated unions are a game-changer in the TypeScript toolbox, empowering you to write more robust, type-safe, and maintainable React components. By harnessing their power, you can ensure consistency and stability as your applications scale. Next time you're faced with dependent conditional props, don't hesitate to reach for a discriminated union - the ultimate problem-solver for a more predictable and efficient codebase.

I hope this post has inspired you to explore the world of discriminated unions in React with TypeScript. Happy coding!

Unlocking how Socket.io can boost your React app's real-time capabilities

Ibukunoluwa Popoola — Sun, 19 May 2024 14:40:18 +0000

As front-end developers, we're familiar with the HTTP protocol, which is the foundation of the web. However, when it comes to real-time communication, HTTP falls short. That's where Socket.io comes in – a JavaScript library using the WebSocket protocol that enables real-time, bi-directional communication between the client and server. In this article, we'll explore the differences between HTTP and WebSocket, and how Socket.io brings new functionalities to the table.

HTTP vs. Websocket: A Brief Overview

HTTP (Hypertext Transfer Protocol) is a request-response protocol, where the client sends a request to the server, and the server responds with a response. This protocol is designed for request-response communication, which is perfect for most web applications. However, when it comes to real-time communication, HTTP is not the best choice.

The WebSocket Protocol is a bi-directional communication protocol that enables real-time, low-latency communication between a client (usually a web browser) and a server over the web. Built on top of the Transmission Control Protocol (TCP), WebSocket inherits TCP's reliability and ordering guarantees, ensuring that data is delivered in the correct order. However, unlike TCP, which is designed for general-purpose networking, WebSocket is optimized for real-time communication, making it an ideal choice for applications that require instantaneous data exchange, such as live updates, gaming, and live support chat.

Socket.io: The Real-Time Solution

Socket.io enables server-initiated communication, allowing the server to proactively push updates to connected clients, eliminating the need for clients to continuously request updates. This is a classic example of the publish-subscribe pattern, a messaging paradigm where a single publisher (the server) broadcasts messages to multiple subscribers (the clients) without them having to explicitly request the information. This one-to-many communication model enables efficient and scalable bi-directional communication, where a single update from the server can be simultaneously received by multiple clients, making it an ideal approach for real-time applications that require instantaneous data dissemination.

A Real-World Example: Integrating Socket.io in a React Typescript Project

I was tasked with integrating a critical feature into an administrative web application, which would subscribe to a server that publishes watchlist events triggered by AI-powered smart cameras detecting vehicles for security purposes. Upon receiving these events, the web app would instantly notify all authorized administrators, ensuring timely awareness and response. Furthermore, administrators could respond to the server, updating the system on actions taken regarding the identified vehicle. This requirement presented a perfect opportunity to leverage bi-directional communication using Socket.io, enabling seamless, real-time exchange of information between the client and server.

In this context, we'll focus exclusively on the frontend implementation. To facilitate this functionality, a WebSocket-enabled server is a prerequisite. In a future discussion, we can explore how to set up a simple Node.js server with WebSocket capabilities.

The first step was to install the necessary dependencies:

yarn add socket.io-client

Then I set up global and scalable functionality for how the application would interact with the Socket.io logic using standard React practice, custom hooks, contexts, and following the guidelines in the socket-io-client documentation.

// useSocket.ts
import { useEffect, useRef } from 'react';
import io, { ManagerOptions, Socket, SocketOptions } from 'socket.io-client';

export const useSocket = (url: string, options?: Partial<ManagerOptions & SocketOptions> | undefined): Socket => {
    const { current: socket } = useRef(io(url, options));

    useEffect(() => {
        return () => {
            if (socket) {
                socket.close();
            }
        };
    }, [socket]);

    return socket;
};

/// IWatchlist.ts
export interface IWatchListSocketResponse {
    id: string;
    // any other props you wish to add
    [key: string]: any;
}
export interface IWatchListActionItem {
    id: string;
    // any other props you wish to add
    [key: string]: any;
}

// watchlistContext.tsx
/* eslint-disable no-console*/
import { ReactNode, createContext, useCallback, useContext, useEffect, useReducer, useState } from 'react';
import { Socket } from 'socket.io-client';
import { useSocket } from 'hooks/generic/useSocket';
import { IWatchListActionItem, IWatchListSocketResponse } from 'interfaces/IWatchlist';
import { WATCHLIST_WS_URL } from 'utils/constants';

export interface IWatchListSocketContextState {
    socket: Socket | undefined;
    watchListInfo: IWatchListSocketResponse[];
    watchListActionItem?: IWatchListActionItem;
}

export type WatchListSocketContextAction = 'update_socket' | 'receive_watchList' | 'attend_to_watchList_item';
export type WatchListSocketContextPayload = IWatchListSocketResponse[] | IWatchListActionItem | Socket;
export type SocketConnectionStatus = 'connecting' | 'connected' | 're-connecting' | 'closed';

export interface IWatchListSocketContextAction {
    type: WatchListSocketContextAction;
    payload: WatchListSocketContextPayload;
}

export interface IWatchListSocketContextReturnProps {
    socketState: IWatchListSocketContextState;
    socketDispatch: React.Dispatch<IWatchListSocketContextAction>;
    connectionStatus: SocketConnectionStatus;
    handleWatchListItem: () => void;
}

const defaultWatchListSocketContextState: IWatchListSocketContextState = {
    socket: undefined,
    watchListInfo: [],
    watchListActionItem: {} as IWatchListActionItem
};

export const WatchListSocketContext = createContext<IWatchListSocketContextReturnProps>({
    socketState: defaultWatchListSocketContextState,
    socketDispatch: () => {},
    connectionStatus: 'closed',
    handleWatchListItem: () => {}
});

export const useWatchListSocketContext = () => useContext(WatchListSocketContext);

const SocketReducer = (state: IWatchListSocketContextState, action: IWatchListSocketContextAction) => {
    console.log('Message received - Action: ' + action.type + ' - Payload: ', action.payload);

    switch (action.type) {
        case 'update_socket':
            return { ...state, socket: action.payload as Socket };
        case 'receive_watchList':
            return { ...state, watchListInfo: action.payload as IWatchListSocketResponse[] };
        case 'attend_to_watchList_item':
            return { ...state, watchListActionItem: action.payload as IWatchListActionItem };
        default:
            return state;
    }
};

export const WatchListSocketContextProvider = ({ children }: { children: ReactNode }) => {
    const [socketState, socketDispatch] = useReducer(SocketReducer, defaultWatchListSocketContextState);
    const [connectionStatus, setConnectionStatus] = useState<SocketConnectionStatus>('closed');

    const socket = useSocket(WATCHLIST_WS_URL, {
        reconnectionAttempts: 5,
        reconnectionDelay: 1000,
        autoConnect: false
    });

    const startListeners = useCallback(() => {
        /** Messages */
        socket.on('connecting', () => {
            console.info('Connecting to WatchList service');
            setConnectionStatus('connecting');
        });

        /** Messages */
        socket.on('watchList_received', (watchList: any[]) => {
            console.info('WatchList info received');
            socketDispatch({ type: 'receive_watchList', payload: watchList });
            setConnectionStatus('connected');
        });

        /** Connection / reconnection listeners */
        socket.on('reconnect', attempt => {
            console.info('Reconnected on attempt: ' + attempt);
            setConnectionStatus('re-connecting');
            console.info('Retrying to get watchList ...');

            socket.emit('retry_watchList', async (watchList: any[]) => {
                console.info('User handshake callback message received');
                socketDispatch({ type: 'receive_watchList', payload: watchList });
            });
        });

        socket.on('reconnect_attempt', attempt => {
            console.info('Reconnection Attempt: ' + attempt);
        });

        socket.on('reconnect_error', error => {
            console.info('Reconnection error: ' + error);
        });

        socket.on('reconnect_failed', () => {
            console.info('Reconnection failure.');
            alert(
                'We are unable to connect you to the watchList service.  Please make sure your internet connection is stable and try again.'
            );
            setConnectionStatus('closed');
        });
    }, [socket]);

    useEffect(() => {
        socket.connect();
        socketDispatch({ type: 'update_socket', payload: socket });
        startListeners();
        // eslint-disable-next-line react-hooks/exhaustive-deps
    }, [socket]);

    const handleWatchListItem = () => {
        console.info('Handling watch list item ...');

        socket.emit('attend_to_watchList_item', async (watchListItem: IWatchListActionItem) => {
            console.info('User handshake callback message received');
            socketDispatch({ type: 'attend_to_watchList_item', payload: watchListItem });
        });
    };

    return (
        <WatchListSocketContext.Provider value={{ socketState, socketDispatch, connectionStatus, handleWatchListItem }}>
            {children}
        </WatchListSocketContext.Provider>
    );
};

// App.tsx (or your apps entry file)
import ReactDOM from 'react-dom/client';
import VehicleAdminApp from './VehicleAdminApp';
import WatchListSocketContextProvider from 'contexts/watchlistSocket';
import reportWebVitals from './reportWebVitals';

const root = ReactDOM.createRoot(document.getElementById('root') as HTMLElement);
root.render(
    <WatchListSocketContextProvider>
        <VehicleAdminApp />
    </WatchListSocketContextProvider>
);

// If you want to start measuring performance in your app, pass a function
// to log results (for example: reportWebVitals(console.log))
// or send to an analytics endpoint. Learn more: https://bit.ly/CRA-vitals
reportWebVitals();

Now, an example of how the socket logic can be used in a component:

// VehicleAdminApp.tsx
import { useWatchListSocketContext } from 'contexts/watchlistSocket';

const VehicleAdminApp = () => {
    const { socketState } = useWatchListSocketContext();
    const { socket, watchListInfo } = socketState;

    return (
        <div>
            <h2>Socket IO Information:</h2>
            <p>
                Your socket ID: <strong>{socket?.id}</strong>
                <br />
                Watchlist items: <strong>{watchListInfo.length}</strong>
                <br />
                <br />
            </p>
        </div>
    );
};

export default VehicleAdminApp;

The provided code establishes a Socket.IO context that manages the socket connection, watch list information, and action items. The WatchListSocketContext is created using the createContext hook, which allows components to access the socket state, dispatch actions, connection status, and a function to handle watch list items. The useWatchListSocketContext hook is also defined for easy access to the context in other components.

The WatchListSocketContextProvider is the heart of the implementation, where the socket connection is established using the useSocket hook. The provider sets up listeners for various socket events, such as connecting, receiving watch list information, and reconnecting. It also defines the startListeners function, which sets up these listeners, and the handleWatchListItem function, which emits an event to attend to a watch list item. The provider returns a context provider that wraps the application, making the socket context available to all components. This implementation provided a solid foundation for building the watchlist functionality in my application.

Conclusion

Socket.io is a powerful library that enables real-time communication between the client and server. By understanding the differences between HTTP and TCP, and how Socket.io uses the WebSocket protocol, you can unlock the power of real-time communication in your React applications.

Implementing Socket.IO in a React application requires careful planning and a thorough understanding of its underlying principles. However, the rewards of real-time communication make it a valuable investment for any React developer seeking to elevate their applications. This article provides a step-by-step guide on how to correctly integrate Socket.IO in a React/Typescript application, using a watchlist feature as a practical example, to help you unlock the full potential of real-time functionality in your projects.

Useful links:

Software Engineering Principles Every Frontend Developer Should Know

Ibukunoluwa Popoola — Sun, 12 May 2024 12:21:26 +0000

As frontend developers, we often focus on creating beautiful user interfaces. However, it's essential to remember that beauty also lies on the inside and the pixel-perfect approach should translate to our code organization and structure as well. In this article, we'll explore some fundamental software engineering principles that every frontend developer should know and apply in their projects.

1. DRY (Don't Repeat Yourself)

The DRY principle emphasizes the importance of code reusability and maintenance. Avoid duplicating code by extracting common functionalities into reusable components, functions, or modules. By adhering to the DRY principle, you can reduce code duplication, improve maintainability, and make your codebase more modular. React encourages a component-driven architecture where responsibilities are segregated for easy development and scalability in the future.

Let's take a products page from a simple E-Commerce application for example. We expect to see a list of products for sale. We can break down the page into smaller, reusable components.

Components:

ProductCard: Displays a single product with its name, price, and description.
ProductList: Displays a list of products.

// ProductCard.js
import React from 'react';

const ProductCard = ({ product }) => {
  return (
    <div>
      <h2>{product.name}</h2>
      <p>Price: ${product.price}</p>
      <p>Description: {product.description}</p>
    </div>
  );
};

export default ProductCard;

// ProductList.js
import React, { useState } from 'react';
import ProductCard from './ProductCard';

const ProductList = () => {
  const [products, setProducts] = useState([
    { id: 1, name: 'Product 1', price: 9.99, description: 'Description 1' },
    { id: 2, name: 'Product 2', price: 19.99, description: 'Description 2' },
    // ...
  ]);

  return (
    <div>
      {products.map((product) => (
        <ProductCard key={product.id} product={product} />
      ))}
    </div>
  );
};

export default ProductList;

In this example, we see that by segregating the logic concerning a product into the ProductCard component, we can re-use this in the map functionality in the ProductList component and avoid duplicated code for every product item in the List page.

2. SOLID Principles

SOLID is an acronym representing five key principles of object-oriented design:

Single Responsibility Principle (SRP): Each module or class should have only one reason to change.
Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification.
Liskov Substitution Principle (LSP): Subtypes should be substitutable for their base types without altering the correctness of the program.
Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they don't use.
Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions.

Let's take a look at how we can apply the Liskov Substitution Principle (LSP) in a React TypeScript component:

// Vehicle.ts
interface Vehicle {
  drive(): void;
  name: string;
}

// Car.ts
class Car implements Vehicle {
  constructor(private name: string) {
    this.name = name;
  }

  drive(): void {
    console.log(`Driving a ${this.name}`);
  }
}

// Motorcycle.ts
class Motorcycle implements Vehicle {
  constructor(private name: string) {
    this.name = name;
  }

  drive(): void {
    console.log(`Riding a ${this.name}`);
  }
}

// App.tsx
import React from 'react';
import { Vehicle } from './Vehicle';
import Car from './Car';
import Motorcycle from './Motorcycle';

function VehicleComponent(props: { vehicle: Vehicle }) {
  props.vehicle.drive();
  return <div>Driving a {props.vehicle.name}</div>;
}

const App = () => {
  const car = new Car();
  const motorcycle = new Motorcycle();

  return (
    <div>
      <VehicleComponent vehicle={car} />
      <VehicleComponent vehicle={motorcycle} />
    </div>
  );
};

export default App;

In this example, we have a Vehicle interface that defines the name attribute and drive method. We then have two concrete implementations: Car and Motorcycle, which both implement the Vehicle interface.

In the App component, we create instances of Car and Motorcycle and pass them to the VehicleComponent. The VehicleComponent calls the drive method on the passed-in vehicle object.

The LSP ensures that we can substitute Car or Motorcycle for the Vehicle interface without altering the correctness of the program. The VehicleComponent works seamlessly with both Car and Motorcycle instances, demonstrating the substitutability of subtypes for their base types.

3. KISS (Keep It Simple, Stupid)

The KISS principle advocates for simplicity in design and implementation. Write code that is easy to understand, straightforward, and does one thing well. Avoid unnecessary complexity and over-engineering, as it can lead to confusion and maintenance challenges in the long run.

Let's look at 2 implementations of a Counter component.

// Complex Counter
import React, { useState, useEffect } from 'react';
import { debounce } from 'lodash';

const ComplexCounter = () => {
  const [count, setCount] = useState(0);
  const [clicked, setClicked] = useState(false);
  const [error, setError] = useState(null);

useEffect(() => {
    if (clicked) {
        setCount(prev => prev + 1)
        setClicked(false)
    }
}, [clicked, setClicked]);

  const handleClick = (clicked: boolean) => {
    setClicked(!clicked);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => handleClick(clicked)}>Increment</button>
    </div>
  );
};

export default ComplexCounter;

// Simple Counter
import React, { useState } from 'react';

const SimpleCounter = () => {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setCount(count + 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={handleClick}>Increment</button>
    </div>
  );
};

export default SimpleCounter;

We see that the ComplexCounter implementation is harder to understand and maintain and more prone to errors.
It introduced an unnecessary state variable for clicked and a useEffect hook.
It's an example of how not to implement a React component.

4. YAGNI (You Aren't Gonna Need It)

YAGNI reminds us to avoid adding functionality prematurely based on speculative future requirements. Instead, focus on correctly implementing the features that are currently needed. This becomes very important when you are building a very user-centric product. It would be best if you tried not to introduce new features on the assumption of what you think users might want. Utilize a proper user research framework and prototyping methods instead.
By following YAGNI, you can prevent unnecessary complexity, reduce development time, and maintain a lean codebase.

5. Clean Code

Clean code is readable, understandable, and maintainable. Follow coding conventions and best practices, use meaningful variable names, and write self-explanatory code. Keep functions and classes small and focused, adhere to consistent formatting, and strive for clarity in your codebase.

Let's take a simple utility function used to conceal parts of a user's private information for Data Security purposes.

const hashUsersPrivateInformation = (privateInformation: string): string => {
  // Calculate the length of the private info to determine how many characters to mask
  const maxLength = privateInformation.length > 4 ? privateInformation.length - 4 : privateInformation.length;
// Create a regular expression pattern to match the desired number of characters
  const regexPattern = `.{1,${maxLength}}`;
  const regex = new RegExp(regexPattern);

  return privateInformation.replace(regex, (match) => '*'.repeat(match.length));
};

We see that:

The function's name is self-descriptive
It includes useful comments to help other developers.
It has a primary purpose that is understandable.

We should aim to structure our code similarly.

Conclusion

Incorporating these software engineering principles into your front-end development workflow allows you to write better-quality code, improve collaboration with team members, and build robust and scalable applications. Software engineering is not just about writing code; it's about creating reliable, maintainable, and elegant solutions to complex problems.