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.