Frontend architecture #18

New issue

Open

opened 2026-09-05 11:31:15 +02:00 by daniel · 1 comment

daniel commented

2026-09-05 11:31:15 +02:00

Owner

Using React bulletproof as a basis, the main architecture for the frontend should be created.

The goal is to have the folder structure and a baseline that allows routing etc. so new pages/modules/features have a blueprint on how to be built

Using [React bulletproof](https://github.com/alan2207/bulletproof-react) as a basis, the main architecture for the frontend should be created. The goal is to have the folder structure and a baseline that allows routing etc. so new pages/modules/features have a blueprint on how to be built

daniel added the

Kind/Feature

Reviewed

Confirmed

labels

2026-09-05 11:31:16 +02:00

daniel self-assigned this

2026-09-06 09:14:59 +02:00

daniel added this to the Development project

2026-09-06 09:15:26 +02:00

daniel commented

2026-09-06 10:13:17 +02:00

Author

Owner

State management
- We could do it with normal hooks (setState etc.) but that is only suitable for state of single components.
- Global state will most likely need better handling
- The library zustand seems like a good choice
- Zustand is also used by react-bulletproof for example for notifications
- Things like light/dark mode or other user theme preferences would also fit well for zustand
Input validation
- Usually we would like to validate the user input, if for example they perform wrong inputs when creating delivery notes and such
- Zod seems to be a good fit. We need to investigate what actually is in the validation result on error so that we can hopefully mark the appropriate fields in the dialog for example.
Forms
- Every dialog and input field is a form. There are libraries that should make the creation of forms very simple
- React Hook Form is one of them. I think this could help us, especially in combination with Input validation. Hopefully this can show errors on specific input fields to work well with validation. If not, we might need another library for that
API calls
- Ideally, we create the api client automatically from an OpenAPI specification we can generate in the backend.
- For automatic API creation we should use HeyApi. It integrates with zod and api clients (see next bullet point)
- There are several clients that wrap the JS native calls. I did not yet investigate any of them though
- An API client should be helpful as it should make error handling a bit easier
Error handling
- API errors are handled above
- Other errors in the app should be contained with ErrorBoundries (default React components)
- I think custom handling can be added in the case an error occurs. If an error occurs we should log that error. OpenTelemetry (OTel) can probably be used to catch these errors and transmit the data to an OTel endpoint. OTel will be implemented in #16.
- Maybe a custom error boundry that wraps the "send to OTel" logic should be implemented. It doesn't need to already send to OTel but it should be prepared so later implementation is easier.
- If OTel doesn't work, there might be other solutions for the job. Sentry could be one of them

This comment is for gathering thoughts on what to use for which part. Its quite comprehensive but also shortened to what react-bulletproof talks about. I decided on many things we use and shortened the "why" so we should be able to start with these sooner than later - State management - We could do it with normal hooks (setState etc.) but that is only suitable for state of single components. - Global state will most likely need better handling - The library [zustand](https://github.com/pmndrs/zustand#typescript-usage) seems like a good choice - Zustand is also used by react-bulletproof for example for [notifications](https://github.com/alan2207/bulletproof-react/blob/master/apps/react-vite/src/components/ui/notifications/notifications-store.ts) - Things like light/dark mode or other user theme preferences would also fit well for zustand - Input validation - Usually we would like to validate the user input, if for example they perform wrong inputs when creating delivery notes and such - [Zod](https://zod.dev/) seems to be a good fit. We need to investigate what actually is in the validation result on error so that we can hopefully mark the appropriate fields in the dialog for example. - Forms - Every dialog and input field is a form. There are libraries that should make the creation of forms very simple - [React Hook Form](https://react-hook-form.com/) is one of them. I think this could help us, especially in combination with Input validation. Hopefully this can show errors on specific input fields to work well with validation. If not, we might need another library for that - API calls - Ideally, we create the api client automatically from an OpenAPI specification we can generate in the backend. - For automatic API creation we should use [HeyApi](https://heyapi.dev/). It integrates with zod and api clients (see next bullet point) - There are several clients that wrap the JS native calls. I did not yet investigate any of them though - An API client should be helpful as it should make error handling a bit easier - Error handling - API errors are handled above - Other errors in the app should be contained with ErrorBoundries (default React components) - I think custom handling can be added in the case an error occurs. If an error occurs we should log that error. [OpenTelemetry (OTel)](https://opentelemetry.io/docs/demo/services/frontend/) can probably be used to catch these errors and transmit the data to an OTel endpoint. OTel will be implemented in #16. - Maybe a custom error boundry that wraps the "send to OTel" logic should be implemented. It doesn't need to already send to OTel but it should be prepared so later implementation is easier. - If OTel doesn't work, there might be other solutions for the job. [Sentry](https://sentry.io/) could be one of them