Add front-end challenge solution

[Douglas1903]

This PR adds my solution for the Front-end Developer Challenge.

The implementation uses React, TypeScript, Redux Toolkit and Material UI 5, covering authentication, machine management, monitoring points, sensor association, business rules validation, pagination, sorting and unit tests.

Assumptions and instructions to run the project are documented in the README.

[calil-amaral-dynamox]

Evaluation: Dynamox Full-Stack Developer Challenge

Candidate Folder: dev-sec-fin-ops-challenge-v1/dynamox-front-end-challenge

---

1 - Authentication

1. As a user, I want to log in using a fixed email and password so that I can access private routes.
2. As a user, I want to be able to log out of the system so that I can prevent unauthorized access to my account.
3. No private routes should be accessible without authentication.

---

2 - Machine Management

1. As a user, I want to create a new machine with an arbitrary name and with a type selected from a list ["Pump", "Fan"] so that I can manage it later.
2. As a user, I want to change the attributes (name and type) of a machine after creating it so that I can keep the machine information updated.
3. As a user, I want to delete a machine when it is no longer in use so that it doesn't clutter the system.

Implemented a confirmation dialog (native, but functional); 👍

---

3 - Monitoring Points and Sensors Management

1. As a user, I want to create at least two monitoring points with arbitrary names for an existing machine, so that I can monitor the machine's performance.
2. As a user, I want to associate a sensor to an existing monitoring point so that I can monitor the machine's performance. The sensor should have a unique ID, and the sensor model name should be one of ["TcAg", "TcAs", "HF+"].

Could not associate unless I filled the id field that explicitly says it is optional; 👎
Choice of letting user select the unique id is valid, but unconventional;

3. As a user, I want the system to prevent me from setting up "TcAg" and "TcAs" sensors for machines of the type "Pump".

Business rule is enforced but only explicit if user fills in the optional ID field, otherwise, the sensor field in the table is not filled but the user has no idea why; 👎
When business rule is enforced and user receives error, the redux error is exposed in the UI instead of adequatelly treated; 👎

4. As a user, I want to see all my monitoring points in a paginated list so that I can manage them. The list should display up to 5 monitoring points per page and should include the following information: "Machine Name", "Machine Type", "Monitoring Point Name", and "Sensor Model".

Paginated list implemented with PAGE_SIZE = 5 in MonitoringPointsPage.tsx. All required columns are displayed. Pagination component from MUI is used. 👍

5. As a user, I want to sort the monitoring points list by any of its columns in ascending or descending order, so that I can easily find the information I'm looking for.

Sorting implemented using TableSortLabel on all columns (Machine Name, Machine Type, Monitoring Point Name, Sensor Model). Uses sortByKey utility function. 👍

Additional filters (search by point name, filter by sensor model) were implemented beyond the requirements. 👍

---

4 - Ambiguity Handling

1. Make reasonable assumptions and design the application accordingly for any ambiguities in the challenge.

Several reasonable assumptions documented:

• Used json-server as mock backend for realistic API integration
• Each monitoring point can have at most 1 sensor
• Deleted machines show as "(máquina removida)" in monitoring points list
  👍

2. Document your assumptions in the README file.

Assumptions clearly documented in the README.md under "🧠 Assumptions (ambiguities handled)" section. 👍

---

5 - Technical Requirements

1. Use TypeScript.

The entire codebase uses TypeScript with proper type definitions in types.ts files under each feature folder. 👍

2. Use React.

React 19.2.0 is used as the UI library. 👍

3. Use Redux for managing global states.
4. Use Redux Thunks or Redux Saga for managing asynchronous side effects.
5. Use Next.js or Vite.

Vite 7.2.4 is used as the build tool (vite.config.ts present). 👍

6. Use Material UI 5 for styling the application.

MUI 7.3.7 is used (latest major version, backwards compatible with MUI 5 patterns). Components like Table, Dialog, Button, TextField, Card, AppBar, Drawer, etc. are used throughout. Custom theme defined in theme.ts. 👍

7. Create reusable components.

AppShell layout component is reusable. Utility functions (pagination.ts, sorting.ts, validation.ts) are well abstracted and reused across pages. 👍

Could benefit from more granular reusable components (e.g., a generic DataTable component). 👎

8. The code is well-organized and documented.

Clean folder structure with separation of concerns:

• features/ for Redux slices and thunks per domain
• pages/ for page components
• routes/ for routing logic
• services/ for API and storage adapters
• utils/ for pure utility functions
• components/ for reusable UI components

README includes clear instructions. 👍

9. The application layout is responsive.

Uses MUI responsive patterns (sx props with breakpoints, Container, responsive Drawer with mobile/desktop variants). 👍
Uses too much inline styling; 👎

10. Ensure correct business logic and behavior with automated unit tests.

Unit tests implemented with Vitest for:

• Validation rules (validation.test.ts)
• Pagination utilities (pagiantion.test.ts) - note: filename has typo
• Sorting utilities (sorting.test.ts)

Tests can be run via npm run test:run. 👍

Tests focus on utility functions; no component/integration tests present. 👎
It was necessary to set environment: 'node' in vitest.config.ts or the tests woudln't run. 👎

---

6 - Bonus

1. Implement your own back-end code. If you pick this option, write it using NodeJS JavaScript runtime.
2. If you choose to implement your own back-end, we encourage you to use either PostgreSQL or MongoDB as a persistence layer.
3. If you choose to use PostgreSQL, use Prisma ORM (or even try Drizzle, or Kysely) to interact with PostgreSQL.
4. If you choose to use MongoDB, use Mongoose ORM to interact with the database.
5. Use Nest.js Framework for the back-end.
6. Use Nx to manage the whole application as a monorepo.
7. Add e2e tests with Cypress.
8. If you were provided with a baseline code, identify any areas of bad code or suboptimal implementations and refactor them.

The default App.tsx from Vite template is still present and unused (contains the Vite + React counter example). This should have been removed or repurposed. 👎

9. Deploy your application to a cloud provider and provide a link for the running app.