Our goal is to continuously improve the quality and accessibility of public healthcare services using digital tools.

Auto deployed to care.ohc.network for develop branch. All pull requests have preview builds powered by Netlify.

• 💬 Comment on the issue if you are willing to take it up, and link the pull request with the issue.
• 🏷️ Tag @ohcnetwork/care-fe-code-reviewers for faster resolution.
• 📸 Attach screenshots in the pull requests showing the changes made in the UI.

npm install

npm run dev

Once the development server has started, open localhost:4000 in your browser. The page will be automatically reloaded when you make edits and save. You will also see any lint errors in the console.

First, set up the CARE local backend by following the instructions in the CARE Backend Documentation.

Create a .env.local file in the root directory of the project :

# Point the frontend to your local backend
REACT_CARE_API_URL=http://127.0.0.1:9000

Once you have the local backend running and loaded dummy data, you can use the following credentials to authenticate:

# Default Local Backend Credentials
ROLE            USERNAME                PASSWORD
----------------------------------------------------------------
Volunteer       volunteer_2_0           Coronasafe@123
Doctor          doctor_2_0              Coronasafe@123
Staff           staff_2_0               Coronasafe@123
Nurse           nurse_2_0               Coronasafe@123
Administrator   administrator_2_0       Coronasafe@123
Facility Admin  facility_admin_2_0      Coronasafe@123

For patient login via phone number:

• In production, an actual SMS with OTP is sent to the provided phone number
• In staging environment, to save costs, SMS messages are not actually sent
• For testing purposes in staging, use the hardcoded OTP: 45612

• Create a branch with branch name of the format issues/{issue#}/{short-name} (example issues/7001/edit-prescriptions) from the latest develop branch when starting to work on an issue.
• Once the changes are pushed to the branch, make a pull request with a meaningful title (example: "💊 Adds support for editing prescriptions" #6369)
• Ensure the issue number is mentioned in the PR with a closing tag by following the PR body template. (Refer: Linking a pull request to an issue)
• Once the code review is done, the PR will be marked with a "Needs Testing" label where it'll be queued for QA testing.
• Once tested, the PR would be marked with a "Tested" label and would be queued for merge.

All strings must be encased in i18n translations. New translation strings must be specified in src->Locale->en. Do not add translations for languages other than english through pull requests. Other language translations can be contributed through Crowdin

CARE can load translation files from a remote URL and fall back to local files for any missing keys.

• Enable remote translations: set REACT_CUSTOM_REMOTE_I18N_URL in your environment.
• Expected remote file path: ${REACT_CUSTOM_REMOTE_I18N_URL}/{lang}.json (for example: https://cdn.example.com/i18n/en.json).
• Local fallback path: /public/locale/{lang}.json in this repository (served as /locale/{lang}.json).
• Merge behavior: remote keys override local; any keys absent in remote are served from local.

Example .env.local:

# Load i18n from a CDN (per-language JSON files)
REACT_CUSTOM_REMOTE_I18N_URL=https://cdn.example.com/i18n

Remote file example (en.json):

{
  "hello_care": "Hello Care Remote"
}

Local file example (public/locale/en.json):

{
  "hello_care": "Hello Care Local",
  "welcome_message": "Welcome to Care"
}

With the above, the app serves:

• hello_care -> "Hello Care Remote" (remote overrides local)
• welcome_message -> "Welcome to Care" (falls back to local as remote is missing)

To ensure the quality of our pull requests, we use a variety of tools:

• Automated E2E Testing: We use Cypress and Playwright for end-to-end testing to automatically verify the functionality and performance of our code.
• Manual Real Device Testing: We use BrowserStack to manually test our code on real devices, ensuring compatibility and functionality across different platforms and browsers.

To run cypress tests locally, you'll need to setup the backend to run locally and load dummy data required for cypress to the database. See docs.

Once backend is running locally, you'll have to ensure your local front-end is connected to local backend, by setting the REACT_CARE_API_URL env.

#.env
REACT_CARE_API_URL=http://127.0.0.1:9000

Once done, start the development server by running

npm run dev

Once development server is running, then run the cypress tests in either of the ways described below.

npm run cypress:run        # To run all tests in headless mode.

npm run cypress:run:gui    # To run all tests in headed mode.

npm run cypress:open       # To debug and run tests individually.

• Failed test screenshots are saved in cypress/screenshots
• All test videos are saved in cypress/videos

To run Playwright tests locally, follow the same backend setup steps as Cypress above.

First, install Playwright browsers:

npm run playwright:install

Then run Playwright tests in one of the following modes:

npm run playwright:test           # Run all tests in headless mode
npm run playwright:test:ui        # Run tests in interactive UI mode
npm run playwright:test:headed    # Run tests in headed mode (visible browser)
npm run playwright:show-report    # View the HTML test report

• Test results and artifacts are saved in test-results/
• HTML reports are saved in playwright-report/

For more details, see tests/README.md.

• CARE Documentation
• Swagger API Documentation
• Testing Documentation

npm run build

Builds the app for production to the build folder. It correctly bundles React in production mode and optimizes the build for the best performance.

npm run preview

Starts a production http-server in local to run the project with Service worker. The build is minified and the filenames include the hashes.

🚀 Your app is ready to be deployed!