Refactoring the maintenance app

[Mohammer5]

As some of you (team platform FE devs) have seen already, I've been working on creating a react 17 app that contains both the legacy maintenance app (with react 15) as well as a modern react 17 app (code).

What I've created is just a PoC, but it highlightes how we could tackle the maintenance app without having to:

• create an entirely new app that can be used in parallel to the old one
• massively refactor the old app (I did have to do some changes, especially in regards to the routing; react-router -> react-router-dom)

Goals

• App-Platform app
• Being able to replace individual sections
• Provide an escape hatch to the legacy section (e. g. by prefixing the route's path with /legacy)
• Once all sections have been completed, we simply want to delete the old code and turn the src/modern folder into the src folder

Current status

• The PoC works. If you want to try it out yourself, clone the repo I've linked to above, open https://debug.dhis2.org/dev, login and then run yarn start (after running yarn (install)) in the PoC repository.
  • I've created an ad-hoc replacement for the data elements list view, everything else is the old app
• The PoC uses react 17, it does not use the app platform. My goal was to figure out whether this approach works at all.
• Currently the api's baseUrl is hardcoded. The legacy app used the $DHIS2_CONFIG env var and the webpack.manifest file. We'll need to figure out how we can pass the correct information to the legacy app.
• The code is quite messy, I have not tried to keep it clean as I was experimenting. We need to talk about the actual architecture. Is there anything we want to reuse (other than the route paths: please no)?

Path forward

I suggest that we go the following way:

• Use the PoC (clone & move to github.com/dhis2) and work on the preferred architecture there
• Copy the PoC's code to the existing maintenance app in order to keep the git history
• Then we can either
  • start working on sections
  • or add the app-platform first
• I assume that it could require some work to get this to work with the app-platform. If that is the case, I think it makes more sense to simply use create-react-app approach (I assume that the react-scripts contain quite a bit of magic to make everything work). Once we've replace all sections and can get rid of the old code, it should be fairly straight forward to port the app to the app-platform. - This is all assuming that it requires quite a bit of work in the app-platform and potentially some guesswork in regards to what needs to be changed in the app-platform. It might be less work to do that work after refactoring the maintenance app, but I don't have an educated opinion, just a gut feeling.

[varl]

Nice work.

Is there anything we want to reuse (other than the route paths: please no)?

We should keep the legacy system separate as we can, ideally it would be "read-only", however that's probably not practical.

or add the app-platform first

I strongly advise that we get the Maintenance app running on the App Platform as first priority as that allows us to enable continuous delivery to the App Hub as we work on it and and not rely on the DHIS2 Core timelines.