Reusable Dialog Component for Add and Edit Operations

“Add” and “Edit” again and again…

In most applications, managing “Add” and “Edit” operations is a fundamental requirement. At first, I created separate modals for each entity—users, products, and orders—thinking it was the simplest approach. How this approach becomes increasingly difficult to maintain as the number of entities grows and leads to these problems:

The problems

●Code Duplication: Each entity (users, products, orders, etc.) requires a separate dialog for both adding and editing.

●Inconsistent UI/UX: Since each dialog is manually created, UI inconsistencies may arise across different components.

●Increased Maintenance Overhead: Any UI or functional update to modals needs to be replicated across all individual dialogs.

What’s the typical Alternatives?

–Separate Add & Edit Dialogs

 ✅Pros: Allows complete customization for each dialog.

 ❌Cons: Leads to repeated code, inconsistency, and increased maintenance efforts.

–One Generic Dialog but Manually Configured Per Page

✅Pros: Reduces some duplication.

 ❌Cons: Still requires repetitive setup, and developers may need to pass multiple props repeatedly.

–Custom Hook for Dialog Logic

 ✅Pros: Helps manage dialog state and form submission logic efficiently.

 ❌Cons: Still requires individual dialogs per use case.

A more scalable approach is to use a single, opinionated dialog component that dynamically adapts based on whether it’s being used for adding or editing. This ensures consistency while reducing redundancy, making it easier to maintain in the long run.

Introducing MutableDialog

The MutableDialog component addresses these challenges by offering a structured way to handle both “Add” and “Edit” operations within a single, reusable dialog box. It integrates seamlessly with React Hook Form and Zod for validation, ensuring robust form handling.

This dialog component is “opinionated”—it follows a defined pattern that standardizes dialog interactions. While it simplifies development in many cases, it also comes with trade-offs, which we’ll explore later.

Core Features:

●Dynamic Behavior: Determines whether it’s in “Add” or “Edit” mode based on the presence of default values.

●Standardized UI: Ensures a consistent user experience across different forms.

●Validation Support: Uses Zod schemas to enforce validation rules.

●Reusable Structure: Accepts custom form components, allowing flexibility within a predefined framework.

Boosting your Productivity with ActionState<T>, Toast Notifications, and Type Safety

The MutableDialog component also includes several features that improve error handling, user feedback, and code maintainability.

1. ActionState<T> for Standardized Server Responses

The ActionState<T> interface provides a structured way for backend or server actions to communicate success or failure messages to the frontend. This ensures consistency in error handling and additional data processing upon success.

1export interface ActionState<T> {
2  success: boolean;
3  message: string | null;
4  data?: T;
5}

●Consistent Error Handling: Since the backend always returns a standardized response, developers don’t need to manually check response formats.

●Predictable Behavior: Ensures that every action (add/edit) provides a clear indication of success or failure.

The data property in ActionState<T> allows additional information to be returned from server actions. This flexibility is useful for uUI updates or logging.

Use Case: Update Person info

Imagine a Person Search feature where admins can update a user’s details (e.g., name, email). Instead of just confirming the update, we return the updated user object so the UI can reflect changes immediately.

Here’s how a server action might handle this:

1export async function editUser(data: { userId: string; name: string; email: string }) {
2  try {
3    const updatedUser = await prisma.user.update({
4      where: { id: data.userId },
5      data: {
6        name: data.name,
7        email: data.email,
8      },
9    });
10
11    return {
12      success: true,
13      message: "User updated successfully.",
14      data: updatedUser, // Returning updated user object
15    };
16  } catch (error) {
17    return {
18      success: false,
19      message: "Failed to update user.",
20    };
21  }
22}

Integrating with MutableDialog in Person Search

When the edit action runs, we update the UI immediately with the returned user data.

1export function UserEditDialog({ user }: UserEditDialogProps) {
2  const handleEditUser = async (data: UserFormData): Promise<ActionState<User>> => {
3    try {
4      const updatedUser = await updateUser(user.id, data)
5      return {
6        success: true,
7        message: `User ${updatedUser.name} updated successfully`,
8        data: updatedUser,
9      }
10    } catch (error) {
11      return {
12        success: false,
13        message: 'Failed to update user' + (error instanceof Error ? error.message : String(error)),
14      }
15    }
16  }
17 }

Instead of just returning a success/failure status, returning the updated object allows the frontend to display the latest data immediately, reducing the need for additional API calls. This approach ensures a seamless user experience with real-time updates.

Explore Person Search App on GitHub: https://github.com/gocallum/person-search

2. User Feedback with Toast Notifications

The MutableDialog component integrates with toast notifications using shadcn/ui’s toast hook. This provides instant feedback to users when an action succeeds or fails.

●Success Messages: When an operation is successful, users receive a confirmation message.

●Error Messages: If validation or server-side errors occur, users are immediately informed.

●Improved UX: Real-time feedback enhances user experience, preventing confusion and reducing unnecessary clicks.

1if (actions.success) {
2  toast({
3    title: "Success",
4    description: actions.message,
5    variant: "default",
6  });
7} else {
8  toast({
9    title: "Error",
10    description: actions.message || "Operation failed",
11    variant: "destructive",
12  });
13}

3. Strong Type Safety with TypeScript Generics

By defining MutableDialog as a generic component with T extends FieldValues, we enforce type safety and flexibility across different forms. This approach ensures that:

●Form data structures are strongly typed, reducing runtime errors.

●Validation schemas (Zod) and form values remain synchronized, improving developer efficiency.

●Developers can reuse this dialog for multiple entities (users, products, etc.) without changing its core implementation.

1export default function MutableDialog<T extends FieldValues>({
2  formSchema,
3  FormComponent,
4  action,
5  defaultValues,
6}: GenericDialogProps<T>) {

Using TypeScript generics makes it easier to enforce constraints and validate form inputs at compile time, ultimately leading to fewer bugs and more predictable behavior.

MutableDialog usage : trigger buttons

Highlight sections can be edit with MutableDialog

Props Overview

MutableDialog accepts the following props:

●formSchema: A Zod schema defining the validation rules for the form.

●FormComponent: A React component responsible for rendering the form fields.

●action: A function to handle the form submission (e.g., adding or updating a user), utilizing ActionState<T> to standardize responses.

●defaultValues: Initial values for the form fields, used for editing existing data.

●triggerButtonLabel: Label for the button that triggers the dialog

●addDialogTitle / editDialogTitle: Titles for the “Add” and “Edit” modes.

●dialogDescription: Description displayed inside the dialog.

●submitButtonLabel: Label for the submit button.

This code defines the MutableDialog component that handles both “Add” and “Edit” operations dynamically by adjusting the dialog content based on whether default values are provided. Now, let’s look at how we can use this component in your application.

Usage Example

Here’s how you can use MutableDialog in your application:

Step 1: Define a Zod Schema

1import { z } from 'zod';
2
3const userSchema = z.object({
4  name: z.string().min(1, 'Name is required'),
5  email: z.string().email('Invalid email'),
6});

Step 2: Create a Form Component

1import { useFormContext } from 'react-hook-form';
2
3function UserForm({ form }) {
4  return (
5    <div>
6      <label>Name:</label>
7      <input {...form.register("name")} />
8      <label>Email:</label>
9      <input {...form.register("email")} />
10    </div>
11  );
12}

Step 3: Use MutableDialog in Your Page

1import MutableDialog from './components/mutable-dialog';
2
3export function UserDialog() {
4  const handleAddUser = async (data: UserFormData): Promise<ActionState<User>> => {
5    try {
6      const newUser = await addUser(data)
7      return {
8        success: true,
9        message: `User ${newUser.name} added successfully`,
10        data: newUser
11      }
12    } catch (error) {
13      return {
14        success: false,
15        message: 'Failed to add user ' + (error instanceof Error ? error.message : 'Unknown error')
16      }
17    }
18  }
19
20  return (
21    <MutableDialog<UserFormData>
22      formSchema={userFormSchema}
23      FormComponent={UserForm}
24      action={handleAddUser}
25      triggerButtonLabel="Add User"
26      addDialogTitle="Add New User"
27      dialogDescription="Fill out the form below to add a new user."
28      submitButtonLabel="Save"
29      defaultValues={defaultValues} 
30    />
31  )
32}

Pros & Cons of MutableDialog

✅Pros

●Simplifies Code: Eliminates the need for multiple modal components.

●Consistency Across UI: Provides a uniform experience for add/edit dialogs.

●Works Well for Standard CRUD Forms: Best suited for simple forms that require a dialog-based interaction.

❌Cons

●Not Ideal for Complex Workflows: If additional business logic or multiple steps are required, this component might not be flexible enough.

●Limited Button Customization: If different button behaviors (e.g., separate “Cancel” and “Close” actions) are needed, additional modifications are required.

●Toast Notifications May Not Be Desired: If a project has a different notification system, the built-in toast functionality may be unnecessary.

Conclusion

By introducing a dynamic, reusable dialog component, I streamlined the way forms are managed across the application. This approach reduces redundancy, improves maintainability, and ensures a consistent user experience.

Whether you’re a solo developer looking to simplify your workflow or part of a larger team aiming for UI consistency, this solution provides a scalable and efficient way to handle “Add” and “Edit” operations seamlessly.