Forem: Marcin Żmudka

Do not use boolean flags for your react state

Marcin Żmudka — Fri, 23 Feb 2024 12:06:57 +0000

Recently, I found myself tasked with refactoring a component designed for displaying posts in a client's web app, I encountered significant complexity. Initially designed as MVP, our app started with just two user actions on a post: delete and edit. However, as the project evolved, we expanded its functionality to include actions like report, hide, and share. Unfortunately, our original approach to manage these actions and trigger the corresponding modals (whether it was a confirmation for deletion or an edit form pre-filled with the post's data) fell short of scalability. We found ourselves entangled in a web of useState hooks, leading to a cluttered and hard-to-maintain component.

In this article, I aim to share the lessons learned from this experience. I'll detail the pitfalls of our initial design and demonstrate a more streamlined approach to managing component state, aiming to improve scalability and maintainability. Whether you're building or refactoring React applications, the insights provided here should help you avoid the complexities we faced and ensure your components are both efficient and easy to manage.

Initial Component Design

Our initial component closely mirrored an example from the Material-UI documentation, featuring a straightforward IconButton that triggers a menu with two items. Selecting an item from this menu would open the corresponding modal. The display logic for these modals relied on individual boolean useState hooks. Each action (be it editing or deleting) had its own useState to control the visibility of its modal, showcasing a direct but fragmented approach to state management.

export default function MoreOptions() {
  const [anchorEl, setAnchorEl] = React.useState<null | HTMLElement>(null);
  const open = Boolean(anchorEl);

  const handleClick = (event: React.MouseEvent<HTMLElement>) => {
    setAnchorEl(event.currentTarget);
  };
  const handleClose = () => {
    setAnchorEl(null);
  };

  const [isEditModalOpen, setIsEditModalOpen] = React.useState(false);
  const [isDeleteModalOpen, setIsDeleteModalOpen] = React.useState(false);

  const handleEdit = () => {
    setIsEditModalOpen(true);
    handleClose();
  };

  const handleDelete = () => {
    setIsDeleteModalOpen(true);
    handleClose();
  };

  return (
    <>
      <Box>
        <IconButton
          aria-label="more"
          id="long-button"
          aria-controls={open ? "long-menu" : undefined}
          aria-expanded={open ? "true" : undefined}
          aria-haspopup="true"
          onClick={handleClick}
        >
          <MoreVertIcon />
        </IconButton>
        <Menu
          id="long-menu"
          MenuListProps={{
            "aria-labelledby": "long-button",
          }}
          anchorEl={anchorEl}
          open={open}
          onClose={handleClose}
        >
          <MenuItem onClick={handleEdit}>Edit</MenuItem>
          <MenuItem onClick={handleDelete}>Delete</MenuItem>
        </Menu>
      </Box>
      <ConfirmationModal
        isOpen={isDeleteModalOpen}
        onClose={() => setIsDeleteModalOpen(false)}
      />
      <ConfirmationModal
        isOpen={isEditModalOpen}
        onClose={() => setIsEditModalOpen(false)}
      />
    </>
  );
}

The Problem & The Solution

As our application evolved and we introduced new functionalities, the number of useState hooks within our component began to expand significantly. With each new feature (be it sharing, reporting, or hiding posts) came an additional boolean useState to manage its modal's visibility. This burgeoning complexity wasn't just a matter of unwieldy code; it posed a real risk to the application's reliability. Consider the scenario where, due to a coding error, multiple states are set to true simultaneously. This could result in overlapping modals, confusing the user and disrupting the user experience.


// Beginning of the component

const [isEditModalOpen, setIsEditModalOpen] = React.useState(false);
const [isDeleteModalOpen, setIsDeleteModalOpen] = React.useState(false);
const [isShareModalOpen, setIsShareModalOpen] = React.useState(false);
const [isReportModalOpen, setIsReportModalOpen] = React.useState(false);
const [isHideModalOpen, setIsHideModalOpen] = React.useState(false);

// Rest of the component

To address these issues, we needed a more scalable and error-resistant approach. The solution lay in consolidating our state management. Instead of maintaining separate states for each modal, we could use a single state variable to track the currently active modal, if any. This approach not only simplifies the state management by reducing the number of useState hooks but also inherently prevents the possibility of multiple modals being open at the same time. By adopting a more centralized state management strategy, we could enhance both the maintainability of our code and the integrity of the user experience.

To streamline our component's state management and address the issues arising from multiple boolean states, we introduced an enum to represent the different modal variants. This enum defines each action (Edit, Delete, Hide, Report, Share) as a distinct value, allowing us to replace the multiple boolean states with a single state variable that tracks the current active modal based on these enum values.


enum ModalVariant {
  Edit = "Edit",
  Delete = "Delete",
  Hide = "Hide",
  Report = "Report",
  Share = "Share",
}

By implementing this enum, we were able to significantly reduce the complexity and volume of our code. The single state variable, now a flag, indicates which modal (if any) should be open at any given time. This approach not only minimizes the risk of having multiple modals open simultaneously but also simplifies the logic for showing and hiding modals. It marks a substantial improvement in our component's maintainability and scalability, demonstrating the power of thoughtful state management in React applications.

Wrap up

In conclusion, our journey from a component cluttered with multiple useState hooks to a streamlined, single-state system highlights the importance of scalable state management in React applications. The initial approach, while seemingly straightforward, led to increased complexity and potential for errors as new features were added. By adopting an enum to represent modal variants and consolidating state management into a single state flag, we significantly enhanced our component's maintainability and reliability.

This refactor not only reduced the amount of code but also improved the overall architecture of our component, making it easier to understand, extend, and debug. It serves as a valuable lesson in the benefits of anticipating future needs and designing our components with scalability in mind. As developers, it's crucial to continually evaluate and refine our approaches to state management, ensuring our applications remain robust and user-friendly as they evolve.

Through this experience, we've seen firsthand how small changes in how we manage state can have a profound impact on our application's complexity and performance. This encourages us to think critically about our design choices and to embrace best practices that promote efficient and effective state management.

The refactored component.

enum ModalVariant {
  Edit = "Edit",
  Delete = "Delete",
  Hide = "Hide",
  Report = "Report",
  Share = "Share",
}

export default function MoreOptions() {
  const [anchorEl, setAnchorEl] = React.useState<null | HTMLElement>(null);
  const open = Boolean(anchorEl);

  const handleClick = (event: React.MouseEvent<HTMLElement>) => {
    setAnchorEl(event.currentTarget);
  };
  const handleClose = () => {
    setAnchorEl(null);
  };

  const [modalVariant, setModalVariant] = React.useState<ModalVariant | null>(
    null
  );

  const handleOption = (variant: ModalVariant) => {
    setModalVariant(variant);
    handleClose();
  };

  const hideModal = () => {
    setModalVariant(null);
  };

  return (
    <>
      <Box>
        <IconButton
          aria-label="more"
          id="long-button"
          aria-controls={open ? "long-menu" : undefined}
          aria-expanded={open ? "true" : undefined}
          aria-haspopup="true"
          onClick={handleClick}
        >
          <MoreVertIcon />
        </IconButton>
        <Menu
          id="long-menu"
          MenuListProps={{
            "aria-labelledby": "long-button",
          }}
          anchorEl={anchorEl}
          open={open}
          onClose={handleClose}
        >
          {Object.values(ModalVariant).map((variant) => (
            <MenuItem key={variant} onClick={() => handleOption(variant)}>
              {variant}
            </MenuItem>
          ))}
        </Menu>
      </Box>
      <EditModal
        isOpen={ModalVariant.Delete === modalVariant}
        onClose={hideModal}
      />
      <DeleteModal
        isOpen={ModalVariant.Edit === modalVariant}
        onClose={hideModal}
      />
      <HideModal
        isOpen={ModalVariant.Hide === modalVariant}
        onClose={hideModal}
      />
      <ReportModal
        isOpen={ModalVariant.Report === modalVariant}
        onClose={hideModal}
      />
      <ShareModal
        isOpen={ModalVariant.Share === modalVariant}
        onClose={hideModal}
      />
    </>
  );
}

Feeling enlightened or have thoughts to share? Leave a reaction below and let's get the conversation started. For more insights and updates, follow me on Dev.to. Your engagement helps us create a vibrant community of developers committed to improving our craft.

Happy coding, and see you on Dev.to!

Taming Badly Typed External Libraries - How Zod Boosts Type Safety

Marcin Żmudka — Mon, 31 Jul 2023 10:07:39 +0000

TL;DR

In our projects, we use AdminJS, an external library that provides a GUI for managing database records. It's a great tool for rapidly creating CRUD interfaces for our clients. However, we ran into some issues with poorly typed code inside the library that made it difficult to integrate with our own custom logic. This is where Zod, a validation library, came to the rescue.

Zod enabled us to create robust type definitions and validate data against those definitions. This helped us to avoid runtime errors and catch issues early in development. In this article, we'll take a look at how Zod helped us to deal with the poorly typed code in AdminJS and how it improved the overall quality of our code.

Challenges with Poorly Typed External Library

When using external libraries, it's not uncommon to run into issues with poorly typed code. This was the case with AdminJS, a library that we used in our projects to provide a GUI for managing database records. While AdminJS is a great tool for rapidly creating CRUD interfaces for our clients, it also presented some challenges.

One of these challenges was creating schemas for the objects that we received from AdminJS. The library provides a Record<string, any> type, which is not particularly useful when it comes to type safety. We needed to define more robust type definitions for our data to avoid runtime errors.

This is where Zod, a validation library, came into play. We used Zod to create schemas for the objects that we received from AdminJS, which enabled us to catch errors early in development and avoid issues in production.

The code snippet above demonstrates how we defined a schema for a dashboard object that we received from AdminJS. We used Zod's object method to create an object schema with three properties: title, project, and type. We also used Zod's nativeEnum method to create an enumeration schema for the type property, which accepts two specific string values.

By creating these schemas with Zod, we were able to define the exact shape of the data we expected to receive, and catch any errors if the data did not match that shape. This helped us to ensure the quality of our code and avoid any issues caused by the poorly typed code in AdminJS.

import { z } from 'zod';

enum DashboardProviderType {
  GRAFANA = "GRAFANA",
  GOOGLE_STUDIO = "GOOGLE_STUDIO"
}

const DashboardProviderTypeEnum = z.nativeEnum(DashboardProviderType);

const DashboardPayloadSchema = z.object({
  title: z.string(),
  project: z.string(),
  type: DashboardProviderTypeEnum,
});

Creating SubSchemas to Handle Specific Data

In the previous section, we defined a schema for the entire payload that we receive from AdminJS. However, in some cases, we might only be interested in a specific part of the payload, or we might not need all the fields from the payload. In such cases, it is useful to create sub-schemas, which define a subset of the original schema.

ZOD provides several methods to create sub-schemas, such as pick, omit, and partial.

In the code snippet provided, we are using these methods to create three different sub-schemas from the original DashboardPayloadSchema:

DashboardTypeSchema: This schema picks the 'type' field from the DashboardPayloadSchema and creates a new schema with only that field.
DashboardPartialSchema: This schema creates a partial schema from the DashboardPayloadSchema, which means that all the fields are optional.
DashboardWithoutTypeSchema: This schema omits the 'type' field from the DashboardPayloadSchema and creates a new schema with only the 'title' and 'project' fields.

Creating sub-schemas can be useful when we want to validate only a part of the object, or when we want to reuse some of the fields in a different schema. It can also help in simplifying the validation logic and making it more readable.

const DashboardTypeSchema = DashboardPayloadSchema.pick({ type: true });
/*
{
    type: DashboardProviderType;
}
*/

const DashboardPartialSchema = DashboardPayloadSchema.partial() 
/* 
{
    type?: DashboardProviderType | undefined;
    title?: string | undefined;
    project?: string | undefined;
}
*/

const DashboardWithoutTypeSchema = DashboardPayloadSchema.omit({ type: true });
/*
{
    title: string;
    project: string;
}
*/

Refining Schemas with Custom Validation

One of the key features of Zod is the ability to refine schemas with custom validation logic. The refine method can be used to add validation rules to a schema, allowing you to ensure that data meets specific requirements before it is processed.

In the following code snippet, we use refine to ensure that the title field in our DashboardPayloadSchema is no longer than 255 characters. If the title is too long, Zod will throw an error with a custom message.

const DashboardTitle = z.string().refine((title) => title.length < 255, {
  message: "Title cannot be longer than 255 chars"
});

const DashboardPayloadSchema = z.object({
  title: DashboardTitle,
  project: DashbaordProject,
  type: DashboardProviderTypeEnum
});

The refine method can also accept asynchronous functions, as shown in the following example. Here, we use refine to ensure that the project field in our schema exists in a database. If the project does not exist, Zod will throw an error with a custom message.

const DashboardProject = z.string().refine(async (projectName) => {
  const project = await getProject(projectName);
  return !!project;
}, {
  message: "Project must exist in database!"
});

const DashboardPayloadSchema = z.object({
  title: DashboardTitle,
  project: DashbaordProject,
  type: DashboardProviderTypeEnum
});

Modifying Validated Values with `transform()`

While validation ensures that the received data conforms to the schema, sometimes you might need to transform the data to a different format or structure. For example, you might need to extract a certain substring from a string or make a database call to fetch additional data based on a received value.

Zod provides the transform() method that allows you to modify the validated values before returning them. The transform() method accepts a synchronous or asynchronous function that takes the validated value and returns the transformed value.

In the following code snippet, we define a DashboardProject schema that refines the received project string to ensure that it starts with the "PR_" prefix. Then, we use the transform() method to remove the prefix before returning the value.

const DashboardProject = z.string()
  .refine((project ) => project.startsWith("PR_"), {
    message: "Project must start with 'PR_' prefix"
  })
  .transform((project) => project.replace("PR_", ""));

DashboardProject.parse("PR_MT"); // => "MT"

You can also use an asynchronous function with transform() to perform more complex operations, such as making a database call:

const DashboardProject = z.string()
  .refine((project) => project.startsWith("PR_"), {
    message: "Project must start with 'PR_' prefix"
  })
  .transform(async (project) => {
    const projectObject = await getProjectObjectFromDB(project);
    return projectObject;
  });

In the above example, the getProjectObjectFromDB() function is an asynchronous function that fetches the project object from the database based on the received project string. The transform() method applies this function to the validated value and returns the result.

Inferring Types and Creating Type Guards

type Dashboard = z.infer<typeof DashboardPayloadSchema>;

// equivalent to:
type Dashboard = {
  title: string;
  project: string;
  type: DashboardProviderType;
};

export const isDashboard = (payload: unknown): payload is Dashboard => {
  return DashboardPayloadSchema.safeParse(payload).success;
};

In the above code snippet, the infer method is used to automatically infer the type of the schema defined by DashboardPayloadSchema. The inferred type is then assigned to a type alias called Dashboard. This allows us to use the inferred type throughout our codebase without having to manually define it.

Next, the code exports a type guard function called isDashboard. A type guard is a function that checks if a value is of a certain type at runtime. In this case, the isDashboard function checks if the provided payload conforms to the Dashboard type, by attempting to parse the payload using the DashboardPayloadSchema. If the parsing succeeds, the function returns true, indicating that the payload is a valid Dashboard. If the parsing fails, the function returns false.

Using type guards like isDashboard can help catch type errors at runtime and make our code more robust, especially when working with data from external sources like APIs or databases where the shape of the data may not be known in advance.

Summary

In this article, we explored how Zod, a validation library, came to the rescue when integrating AdminJS, an external library with poorly typed code. AdminJS provides a Record<string, any> type, leading to type safety issues. Zod helped us create robust type definitions and validate data against those definitions, catching errors early in development.

We defined a schema for a dashboard object using Zod's object and nativeEnum methods, ensuring the expected data shape. We also created sub-schemas with pick, omit, and partial for specific parts of the payload. Custom validations were added with the refine method to enforce requirements like string length and database existence.

Zod's transform method allowed us to modify validated values, and we learned how to infer types using infer, creating type guards to catch type errors at runtime. Overall, Zod improved code quality and reduced runtime errors, making our integration with AdminJS more efficient and reliable.