Proposal to Refactor Entire Frontend using React and Next.js

[matbrgz]

Overview:
The current frontend architecture may benefit from a complete refactor, transitioning to React.js with Next.js for improved performance, maintainability, and scalability.

Benefits:

1. Performance: React and Next.js offer optimized rendering and efficient client-side navigation, enhancing overall application performance.

2. Developer Experience: Modern frontend tooling, modular components, and a declarative approach to UI development can significantly improve the developer experience and code maintainability.

3. SEO Optimization: Next.js provides server-side rendering (SSR) out of the box, which contributes to better SEO performance and faster page loads.

4. Code Splitting: Next.js enables automatic code splitting, leading to smaller initial page loads and faster navigation between pages.

5. TypeScript Support: TypeScript can be seamlessly integrated into a React and Next.js setup, enhancing code quality through static typing.

Proposed Action:
Initiate a proof of concept (PoC) to demonstrate the benefits of refactoring the frontend using React and Next.js. This involves:

1. Setup: Create a new Next.js project and migrate a small part of the existing frontend to validate the feasibility.

2. Integration: Assess the integration of React and Next.js with the existing backend, ensuring a smooth transition without disrupting current functionalities.

3. Performance Metrics: Measure and document performance improvements using metrics such as page load times, rendering speed, and network requests.

4. Developer Feedback: Gather feedback from the development team on their experience with the new stack, including any challenges faced during the transition.

5. Stakeholder Review: Share the PoC results with stakeholders, highlighting the potential advantages and addressing any concerns or considerations.

Note:
This proposal is intended to kickstart discussions around the possibility of improving our frontend architecture. The PoC aims to provide tangible evidence of the benefits associated with migrating to React and Next.js.

[JunioCalu]

Could you also take charge of doing this, @matbrgz?

[matbrgz]

Yes, Certainly! I'll be taking charge of the frontend migration and would like to initiate discussions on the technical considerations and potential technical debt associated with the proposed changes.

Technical Considerations and Technical Debt:

1. Library Versions:

   • We need to carefully select and upgrade the versions of the following libraries:
     • radix-ui
     • next (considering either version 13 or 14)
     • react (for compatibility with React 18)
     • tailwind
     • shadcn ui
     • typescript
     • zod

2. Configuration Settings:

   • Discuss and define the necessary configurations for tools like:
     • prettier
     • husky

3. React 18 Compatibility:

   • Ensure that the selected versions of react and next are compatible with React 18 features and updates.

4. Migrating to TypeScript:

   • Address the steps and potential challenges in migrating to TypeScript.
   • Discuss how TypeScript will enhance the overall codebase.

5. Dependency Management:

   • Evaluate the impact of the changes on existing dependencies.
   • Plan for updates or replacements where necessary.

6. UI Component Library (radix-ui):

   • Assess the impact and benefits of integrating radix-ui for UI component management.

7. Tailwind and Shadcn UI:

   • Discuss the integration of Tailwind CSS and Shadcn UI and how they align with our styling needs.

8. Prettier and Husky:

   • Define and document the coding standards and configurations for prettier and husky.

9. Additional Technical Debt:

   • Identify and discuss any other technical debt or considerations that may arise during the migration process.

Next Steps:

1. Discussion Meeting:

   • Schedule a meeting to discuss the points mentioned above.
   • Encourage input and insights from team members.

2. Documentation:

   • Document the agreed-upon configurations, decisions, and any action items arising from the discussion.

3. Implementation Plan:

   • Develop a detailed implementation plan based on the outcomes of the discussion.

---Edit:

Some shadcn ui screenshots, they look simple and intuitive:

[jb-alvarado]

@matbrgz, I like that you are enthusiastic about getting involved and I don't want to stop you from that. Personally I'm not interested in a migration to React, not long ago I rewrote the frontend already in Nuxt 3. Most of you points can also be realise in Nuxt, for example it can SSR and is also SEO friendly, but at the moment I don't see that both things a needed. The frontend was not made to share something public, so it don't need to be found by google. SSR is also not needed and by purpose I disable it. At the moment I can just embed the frontend in the binary, and no extra packages needs to be installed.

To switch to tailwind, maybe also with daisyui I can image and if people are interested also in maintaining feature I have no problem with extending the frontend.

Anyway ffpapi can act as a normal API, so everybody can write his one frontend.