Frontend Developer Guides
Development Process
Coding Standards and Patterns
For new work:
General Principles
- New frontends should be micro-frontends encapsulating a core part of the overall interface/domain, for example The Deputy Hub or Workflow Management. This prevents us building a frontend Monolith that is hard work on in isolation.
- Use server-side rendering unless you have a really good reason not to.
Working practices
- Use esbuild to build client-side scripts from your source (see Workflow repo for an example)
- Build your main JS file from modular pieces using E6 modules and imports.
- Use Jest for testing individual components
- All JavaScript should be in a separate, versioned JS bundle file, not inline in HTML. This prevents being blocked by the content security policy and caching issues.
- Use event delegation if you can to avoid unneeded unbind/rebind of events
- User data-attributes for Javascript hooks, not classes. This prevents coupling your behaviour to CSS presentation details.
- Use modern ES6 syntax. As an internal system we know the browsers used to access Sirius, so can use ES6 without Babel transpilation.
- We use JSON-server for mocking API calls on the Supervision side.
Code Quality
- Use eslint and Prettier to keep your code cleanly formatted
- Run Lighhouse over your work to ensure it is performant
- Use the Axe plugin with Cypress to do accessibility checks as part of your tests
Legacy Supervision Angular App Front End
We are deprecating the older Angular app in favour of GDS styled micro-frontends. This documentation is retained for reference purposes only.
- Supervision Front End (Angular)
- Source Map Analysis
- Legacy Frontend Coding Patterns
- Timeline
- Package Updates
This page was last reviewed on 24 March 2023.
It needs to be reviewed again on 24 September 2023
by the page owner #opg-sirius-develop
.
This page was set to be reviewed before 24 September 2023
by the page owner #opg-sirius-develop.
This might mean the content is out of date.