TaskFlow

Frontend Implementation

TaskFlow is a modern, responsive project management and task tracking application designed to help teams organize their work efficiently. It offers a Kanban-style task board, project management capabilities, a secure authentication flow, and dark mode support.

1. Overview

This project is a Frontend-only implementation of TaskFlow built against a mock API specification using MSW (Mock Service Worker). It features a polished interactive UI and is containerized via Docker for seamless setup.

Technology Stack:

• Frontend Framework: React 19 with TypeScript
• Build Tool: Vite
• Styling: Tailwind CSS v4 and shadcn/ui (Radix UI primitives)
• Routing: React Router v7
• API Mocking: Mock Service Worker (MSW)
• Drag & Drop: @hello-pangea/dnd
• Testing: Vitest, React Testing Library, and jsdom

2. Architecture Decisions

Frontend-Only approach with MSW

I opted to focus heavily out on providing a polished, interactive frontend and implemented an in-memory mock backend via MSW.

Project structure

I structured the projects by diving different parts of code into different directories based on their use case. Like page level components go to pages, reusable components into components, mock related stuff into mocks and so on while being imported via barrel export. This offered proper segregation and shared management of code for easier handling and importing.

Component Structure & UI

I selected shadcn/ui as I have had experience with it before it offers a lot of components that were easy to inject into the codebase.

State Management

Used React Context (AuthContext, ThemeContext) and standard hooks primarily instead of Redux or Zustand. The application state is localized where possible (e.g., project details, task boards), avoiding heavy global state boilerplates.

QA, Formatting & Linting

I introduced a coordinated ESLint and Prettier setup (to avoid rule overlap) to enforce strict formatting. I also added a suite of tests utilizing Vitest and React Testing Library to unit-test critical components robustly.

Tradeoffs & What Was Intentionally Left Out

• Persistence: Since the scope was limited to frontend backend is left deliberately however the option to integrate a real backend is totally possible by disabling the mocks from the environment variable.
• More mature and extensive test cases Since my main focus was on implementation and completion I could not provide much effort into testing deeply.
• Styling: Styling was implemented on a very superficial level considering I tend to spend huge amounts of time perfecting the component styled upto near pixel and since I did not have much time to spend in designing and styling I went with a very basic implementation.

3. Running Locally

The easiest way to run the application is using Docker. Ensure you have Docker desktop and Docker Compose installed.

# Clone the repository
git clone https://github.com/AmanSingh81757/taskflow.git
cd taskflow

# Copy the example environment variables
cp frontend/.env.example frontend/.env

# Build and start the container
docker compose up --build

(Please note to keep the value of mock flag as TRUE (ALL CAPS) dont change to lowercase)

The application will be accessible at http://localhost:3000.

(Note: To run the project locally without Docker, please check the Frontend README for deeper instructions.)

4. Test Credentials

To quickly evaluate the UI without needing to register, you can log in immediately using the seeded mock credentials:

Email:    test@example.com
Password: password123

• Besides this you can also register a new user however that new user wont have any projects or tasked assinged initially.

• You can login via the test credentials and view the seeded projects and tasks.

• While loggin in from another user you can also view some projects that user is a part of.

Email:    jane@example.com
Password: password123

• You can also see the admin of a project having edit access to the project details but other members not having the same.

(Note: You can also register a new account naturally, which will be stored in memory before refreshing the page).

5. API Reference

Network traffic is intercepted using MSW and served from mock handlers. The API contract strictly follows the Appendix A: Mock API Spec. The endpoints handled asynchronously include:

• POST /auth/register
• POST /auth/login
• GET /projects
• POST /projects
• GET /projects/:id
• PATCH /projects/:id
• DELETE /projects/:id
• GET /projects/:id/tasks
• POST /projects/:id/tasks
• PATCH /tasks/:id
• DELETE /tasks/:id

6. What You'd Do With More Time

Honest reflections on features I would add or improve:

1. Global Server State Management: Implement TanStack Query (React Query) for better caching algorithms, background fetching, and built-in optimistic UI updates when dragging tasks across columns.
2. End-to-End Testing: While unit and integration tests are present via Vitest, adding Playwright or Cypress to test critical integration flows (like Auth redirection and Drag-and-drop mechanics) in a headless browser would add significant UI stability confidence.
3. Real Backend Integration: Swap out MSW for a persistent backend server written in Go with a PostgreSQL database, introducing real-time task board collaboration via WebSockets so multiple teammates can move issues contemporaneously.
4. Enhanced UX micro-interactions: Adding skeleton loaders for visual progression arrays and localized toast notifications for granular API failures.
5. Add comprehensive styling and design: Adding more styles and designing to the components and making it more presentable and user-friendly.
6. Add more complex database relations: If worked on backend I would have added complex relations between projects, tests, and users to enable much more secure access and well defined relations of all the entities of the application.