Front-end for TIS Self-Service app
Full Tech and Architecture are described elsewhere. The front-end uses REST interaction with the back-end service(s).
Next.js is used to build the app. It is now the industry standard for building an enterprise-level React applications. It gives lots of out-the-box features such as code-splitting and build optimization and allows full control over the underlying configuration. It will also allow for SSR as and when we decide (which can be on a component-by-component basis) which will improve UX. We are currently in the process of migrating fully to Next.js so the app is still a SPA. The app is written in TypeScript using the React library.
- React Router for Routing
- Redux Toolkit for State Management
- Redux-Thunk middleware (for e.g. handling asynchronous redux actions)
- Axios for HTTP communication
- nhsuk react components for UI design
- Jest for unit and snapshot testing
- Cypress for E2E testing amd Component Testing (CT)
The thread can be picked up from the Jira ticket Identify Core React Libraries
npm run dev runs the app in the development mode.
Open http://local.tis-selfservice.com to view it in the browser.
The page will reload if you make edits.
You will also see any lint errors in the console.
Note: To populate the form with data, you will need to run the Docker containers to start the back-end services. See dev-handbook for more details on these services.
Sign in BrowserStack with your work email. Start a web testing session by clicking Live on the menu bar. You can enter the URL of TSS Preprod/Prod for testing.
Clicking Switch browser on the left side menu, you may choose different browsers / OS / mobile devices to test with.
In a Live session, enable Local testing from the left side menu. Follow the instructions to download the BrowserStack Local app if it is the first time config. Enable Resolve all URLs through my network in the setting. Enter your localhost URL in the remote browser's address bar for live local test.
For more information visit (https://www.browserstack.com/docs/live/local-testing#enable-local-testing)
Unit tests are found in the __test__ folders throughout the app and end with .test.ts .
npm test launches the test runner in the interactive watch mode.
See the section about running tests for more information.
RTL component tests are also in the __test__ folders and end with .test.tsx
Cypress CT are found in the cypress/component folder and end with cy.tsx .
npm run ct:headless will run CT in headless mode.
npm run ct will allow you to view the CT in the browser. For more information visit (https://docs.cypress.io/guides/component-testing/overview)
Cypress e2e tests are found in the cypress/e2e folder and end with spec.ts .
Before you can run the e2e tests (logging in as an authorised user using a One Time Pass Code), you will need to add a cypress.env.json file to the root of your project folder:
{
"username": "end.tester@hee.nhs.uk",
"password": "xxxxxxxx",
"secret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
npm run cypress:headless will run the e2e tests in headless mode with Cypress.
npm run cypress will allow you to view the e2e tests in the browser. For more information visit (https://docs.cypress.io/guides/end-to-end-testing/writing-your-first-end-to-end-test)
npm run build generates an optimized version of your application for production. This standard output includes:
- HTML files for pages using getStaticProps or Automatic Static Optimization
- CSS files for global styles or for individually scoped styles
- JavaScript for pre-rendering dynamic content from the Next.js server
- JavaScript for interactivity on the client-side through React
This output is generated inside the .next folder.
See the section about deployment for more information.
When deploying to preprod the ENV environment variable should be set to
preprod, allowing the correct dotenv file to be loaded.
Note that e2e tests are not run as part of the suite of automated PR tests. They are only run after a PR is merged and built: they are run against the resulting preprod instance.
This means that you need to run the e2e tests locally (which you should be doing anyway) and not rely on the PR / Sonarcloud automated checks to avoid deploying failing code to preprod.