Skip to content

Latest commit

 

History

History
81 lines (57 loc) · 3.12 KB

README.md

File metadata and controls

81 lines (57 loc) · 3.12 KB

Maintenance app (beta)

These docs are about the refactoring of the maintenance app. We're actually not refactoring any code, we'll rewrite the app section by section.

On Nov 14, 2022 we decided that from the various options, we'll have a side-by-side app, that's the MVP. We think it'd be nice to have manual interlinking (the user has to navigate explicitly to the new app; we thought about having automatic interlinking from the new app to the old one when clicking on a link to a section that hasn't been implemented yet. This option has yet to be explored by the entire team).

Specific topics

Decisions

Decisions will be recorded with ADRs. A template for new decisions can be found here, which has been copied from the "Markdown Any Decision Records"'s repository.

All decisions can be found in the decisions folder.

General strategy

There are several challenges when it comes to the maintenance app:

  • We want to be able to rely as little as possible on config
  • We want generic pages/sections to be componsed from the same functionality
  • We want the different frontend teams at DHIS2 to be able to work on particular sections

We've decided that we'll create a skeleton app with a functional navigation first. Then we can tackle the first section.

As some of the challenges are new and the app is complex (and a few sections are complicated as well), we:

  • regard everything as an experiment that can be rolled back in case we realize that we've taken a wrong direction
  • try to adhere to proper composition patterns, so that when a particular section / piece of code is somehow different from the rest, we can co-locate that difference with that particular section without having to complicate

Open discussions

We'll use this document for now to document question that have to be answered and the decision that we'll end up with.

For now we have to answer the following question, not necessarily before working on the project though but before it's relevant to make a decision:

state management

How do we manage client-side state?

  • open questions
    • Do we have a per-route state or global, re-usable state?
  • stack options
    • redux
    • zustand

How do we handle url state?

Do we want to copy anything from "mar-y"?

A duplicate fo the old code has been put here.