Contact Form Workflow Logic

Relevant source files

The following files were used as context for generating this wiki page:

• workflows/contactForm.ts
• features/contact/components/ContactApp.tsx
• features/contact/hooks/useContactForm.ts
• workflows/contactForm.test.ts
• messages/en.json
• lib/content.ts

The Contact Form Workflow Logic defines the state management and submission lifecycle for the contact feature within the portfolio application. It utilizes a unidirectional data flow pattern, employing a reducer to manage transition states between user input and form submission feedback.

This system is designed as a demonstration workflow; while it handles the UI states for submission, it currently simulates a network round-trip rather than persisting data to a backend. It is integrated into the "Contact" application window as part of the broader window management system.

State Management Architecture

The workflow relies on a finite state machine pattern implemented via a Redux-style reducer. The state tracks the current status of the form, which dictates the UI behavior, such as disabling buttons or displaying success/error messages.

State Transitions

The form exists in one of four primary statuses:

• idle: The initial state where the form is ready for input.
• submitting: The state during the simulated asynchronous operation.
• success: The state after a successful resolution.
• error: The state if a rejection occurs.

Key Data Structures

Type	Definition	Description
ContactStatus	"idle" | "submitting" | "success" | "error"	The possible functional states of the form.
ContactState	{ status: ContactStatus }	The object representing the current workflow state.
ContactAction	submit | resolve | reject | reset	The dispatched events that trigger state changes.

Sources: workflows/contactForm.ts:1-12

Component Integration

The logic is consumed by the ContactApp component through a custom hook, useContactForm. This hook abstracts the useReducer implementation and the simulated asynchronous submission logic.

Form Submission Flow

When a user submits the form:

1. The submit action is dispatched, moving the state to submitting.
2. A 700ms delay is triggered to simulate network latency.
3. The resolve action is dispatched, moving the state to success.

Localization and Metadata

The contact form supports internationalization (i18n) through next-intl. Labels, placeholders, and status messages are dynamically loaded based on the current locale (e.g., English or Persian).

Form Fields and Content

The contact interface includes fields for Name, Email, and Message, alongside external contact links.

Field/Link	Data Source	Usage
Name	messages/en.json	Input label for the user's name.
Email	messages/en.json	Input label for the user's email address.
Message	messages/en.json	Textarea label for the user's message.
contactEmail	lib/content.ts	The target email address for mailto links.
socials	lib/content.ts	List of social media links (e.g., GitHub, LinkedIn).

Sources: messages/en.json:44-53, lib/content.ts:44-50, features/contact/components/ContactApp.tsx:43-62

Implementation Details

The core logic is contained within the contactReducer function, which ensures predictable state transitions.

export function contactReducer(
  state: ContactState,
  action: ContactAction,
): ContactState {
  switch (action.type) {
    case "submit":
      return { status: "submitting" };
    case "resolve":
      return { status: "success" };
    case "reject":
      return { status: "error" };
    case "reset":
      return { status: "idle" };
    default:
      return state;
  }
}

Sources: workflows/contactForm.ts:14-30

The ContactApp component uses these states to conditionally disable inputs and style feedback:

• The submit button is disabled when status === "submitting".
• A green success message appears when status === "success".
• A red error message appears when status === "error".

Sources: features/contact/components/ContactApp.tsx:31-41

Conclusion

The Contact Form Workflow Logic provides a robust foundation for handling user interactions within the portfolio. By separating state logic into a dedicated reducer and workflow file, the system ensures that form behaviors are testable and maintainable, even as a demonstration feature.