React stack modernization

[jpye-finch]

Our frontend is getting fairly complicated - and some parts outdated - given it's written with modern technologies. Some patterns are getting old and are not being learned by new developers. We need to actively continue refactoring the frontend to keep it modern and exciting for developers to use.

• Migrate class components to function components

Status: 🟢 ongoing work by the core team and @Eezi ❤️

• Extract complex logic to hooks; familiarize using reusable hooks for the team to separate view and logic

• redux-toolkit to help with Redux usage

Status: 🟠 Let's begin using. https://redux-toolkit.js.org/introduction/why-rtk-is-redux-today

Let's start using redux-toolkit and utilizing Apollo and its cache more. Let's get into a mindset to avoid state management. Often what first feels like a new global state is needed, is achieved via the Apollo's data fetching tools or URL parameters. If a use case cannot be solved with those, let's use redux-toolkit.

• Rework workqueues

Status: 🟢 https://github.com/opencrvs/opencrvs-core/issues/7073 picked for 1.7

https://github.com/opencrvs/opencrvs-core/blob/develop/packages/client/src/views/OfficeHome/inProgress/InProgress.tsx

Problems:

• complex logic in the component itself (see transformRemoteDraftsContent)
• the workqueues share a lot of duplicated code

• the pattern how data flows into workqueues is complicated

  Solutions:

• share code with hooks between workqueues
• fetch data from the workqueues themselves with Apollo hooks
• cache the workqueues for offline with Apollo
  

• Rework submission middleware

Status: 🟡 could be simplified within the workqueue rework. There are bits in the submission middleware that update the workqueues

https://github.com/opencrvs/opencrvs-core/blob/develop/packages/client/src/declarations/submissionMiddleware.ts

Submission middleware is a centralized place for submitting different events and actions. It can grow to be a difficult to read function figureOutWhatsHappening(declaration) => Promise<APIResponse> utility that grows and grows. We want to cut the paths early and create more specific handlers for event right after the submit action is done by the users. Middlewares in general can be a bit hidden compared to declarative functions.

Lets investigate how we could simplify it and move parts closer to the actual birth, death, marriage, etc. events and the actual form.

• Upgrade React Router to v6

Status: 🟢 In backlog: https://github.com/opencrvs/opencrvs-core/issues/7682

• [ ] Investigate whether we could move to using pure links instead of onClick-functions

• Upgrade React to 19

Status: 🔴 in beta, not worth considering in 2024

[tareq89]

For central state management library, can Zustand be a candidate? It is catching up very fast and have hooks like familiar interface.

https://npm-compare.com/@reduxjs/toolkit,zustand,jotai,recoil,valtio/#timeRange=ALL

[Zangetsu101]

React Router v6

• Nested routes increasing composability
• Parallel data loading with nested routes
• Easier handling of search params with new hooks
• Better form handling using Web Standards API
• Suspense & error handling support and lots more: https://reactrouter.com/en/main/start/overview

The other thing about search/route params is that we should consider using some runtime validations(e.g. zod) and proper error handling for incorrect values

[Zangetsu101]

Another thing to consider is how we want to handle the offline data which is crucial for us. Is using a library sufficient for us? Are there any use cases that require a more custom solution perhaps?

[naftis]

For central state management library, can Zustand be a candidate? It is catching up very fast and have hooks like familiar interface.

npm-compare.com/@reduxjs/toolkit,zustand,jotai,recoil,valtio/#timeRange=ALL

Yep it's a good option if we need to build/refactor our centralized state management. Here is a interesting comparison about the differences in the state management tools from Jotai's website: https://jotai.org/docs/basics/comparison

Out of them all I think Recoil is something we should skip as it seems stale compared to zustand/jotai.

[naftis]

Another thing to consider is how we want to handle the offline data which is crucial for us. Is using a library sufficient for us? Are there any use cases that require a more custom solution perhaps?

Definitely..

Could we suffice with Apollo doing most of offline caching? If there's something special (like PIN) we need to add to localStorage we could listen to the changes using Jotai https://jotai.org/docs/utilities/storage or Zustand https://docs.pmnd.rs/zustand/integrations/persisting-store-data

This would require refactors like location tree being fetched from gateway