This are general information on how this app works internally. If you need info on a specific section, please refer to the section's docs:
- Standard report
- Data set report
- Reporting summary rate
- Resource
- Organisation unit distribution report
Other topics that might be interesting:
As we're using redux thunk, there's no way to react to the
route-change action. We therefore provide the action thunk
that will load the initial data to the root component of each
section, which will be called in the componentDidMount method.
Most sections share data that needs to be loaded only once, e. g. the organisatin units. These will be loaded in the App.js
Some data is cruicial for the app to function correctly.
There's a blockUi selector, used by the Loader component,
in order to prevent the user from interacting with the app while
it's not ready.
Some loading states won't require to prevent the user from interacting with the UI, like dynamically loading form select options. While the respective select should be disabled, there's no reason to prevent the user from editing the other form fields.
There are two different components for giving feedback:
While the Loader component simply shows a loading spinner and prevents the user
from interacting with the UI, the Snackbar provides information to the user and
can require confirmation for certain action (e. g. deleting resources) but doesn't
prevent the user from doing other actions (which will be handled as a cancel when
the Snackbar asks for confirmation).
The configuration of the Feedback component (snackbar type, message and onActionClick) is stored in its own redux state. As some section will include functionality that required confirmation, such as deleting items from the DB, each section has it's own Snackbar component. To prevent actions from being stored in the state, the onActionClick callback which is required by the Feedback component when asking for confirmation, has to be provided during rendering.