This tool allows the exploration of data on investments and results in the fight against AIDS, tuberculosis and malaria around the world.
The Global Fund invests in smart, effective health programs to end AIDS, tuberculosis and malaria as epidemics. The Data Explorer visualizes where our investments come from, where they are and what they achieve by providing pledge and contribution data, grant financial data, and results data at global, regional and country levels.
We regularly improve and enhance the Data Explorer, and those updates are noted on the Data Explorer Updates page on the Global Fund website. The data behind the Data Explorer and our API are available through the Global Fund Data Service .
It makes use of Data API Middleware in order to retrieve all data needed for the visualisations/tables/filters and detail pages.
- Website: data.theglobalfund.org
- Authors: Zimmerman
- Github Repo:
In order to be able to successfully run or build the app you need to create an environment file .env in the project root directory and fill it with the following:
REACT_APP_API=<data middleware api url>
REACT_APP_MAPBOX_TOKEN=<mapbox account token>
REACT_APP_GOOGLE_ANALYTICS_ID=<google analytics app id>
REACT_APP_CMS_API=<strapi cms api url>
REACT_APP_CMS_TOKEN=<strapi cms api token>
REACT_APP_API: is the url where the data middleware API runs on. If running Data API Middleware locally then you can use http://localhost:4200.
REACT_APP_MAPBOX_TOKEN: to get a mapbox token you will need to register on their website.The token will be used to identify you and start serving up map tiles. The service is free until a certain level of traffic is exceeded.
REACT_APP_GOOGLE_ANALYTICS_ID(optional): Google Analytics ID in order to be able to make use of Google Analytics services.
REACT_APP_CMS_API: is the url where the Strapi CMS API runs on. The project/de branch.
REACT_APP_CMS_TOKEN: is the API token retrieved from the Strapi CMS interface.
In the project directory, you can run:
Installs all necessary dependencies.
Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.
The page will reload if you make edits.
You will also see any lint errors in the console.
Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
See the section about deployment for more information.
Cypress is used for end-to-end testing to ensure that the application functions as expected in the browser. To run the Cypress tests, follow these steps:
In addition to the env variables above the following is also needed for cypress tests to run successfully:
REACT_APP_BASE_URL
REACT_APP_BASE_URL: This is the url your application runs on locally it's usually http://localhost:3000
If you haven't already installed Cypress, ensure all dependencies are installed by running:
Ensure your application is running before starting the Cypress tests. You can do this by running:
Open the Cypress Test Runner by running:
Alternatively, you can run all Cypress tests in headless mode (without the GUI) directly from the command line using:
You can learn more in the Create React App documentation.
To learn React, check out the React documentation.
- As we use semantic-release for automated git releases your commits must comply with the following commit types:
feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing or correcting existing tests
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
- Always try to reference issues in commit messages or pull requests ("related to #614", "closes #619" and etc.).
- Avoid huge code commits where the difference can not even be rendered by browser based web apps (Github for example). Smaller commits make it much easier to understand why and how the changes were made, why (if) it results in certain bugs and etc.
- If there's a reason to commit code that is commented out (there usually should be none), always leave a "FIXME" or "TODO" comment so it's clear for other developers why this was done.
- Automatic code quality / testing checks (continuous integration tools) are implemented to check all these things automatically when pushing / merging new branches. Quality is the key!