Principles for building web applications

1. Use TypeScript

2. Use React

3. Use Gjensidige's design system, Builders Core

It's expected that you contribute to our libraries when there is something that is missing, or does not work as expected. Reach out to us on Slack.

4. Use Vite, or Vanilla CRA

Unless you have a well defined reason for other options.

5. Use React Router (if applicable)

6. Have a clear plan for state management

If using state management outside of what React offers, use Redux Toolkit

7. Use our log and error handler

8. Keep your dependencies in check and up to date

Use exact versioning for dependencies to keep your builds deterministic: npm config set save-exact=true. Use dependabot for keeping them up-to-date.

Actively look for and eliminate any security issues.

Replace deprecated functionality and libraries sooner than later.

9. Have a clear linting-strategy, using ESlint, prettier, etc.

Linted code is easier to read, and therefor maintain. It helps minimize errors and confusion, and having it installed in your IDE makes for a smooth dev experience.

We longer maintain our own overwrites/configurations for this, and advise you to use defaults, or your own standards.

10. Sane commit messages

Some teams use conventional commits to make their commits human and machine readable. This is not required, but all teams should strive for some form and consistency, and having descriptive messages.

11. Our applications are simple to run and test

We store mock data alongside our projects so they can be run locally without much hassle.

PS: Mock data should never contain sensitive or secret values (like passwords, SSN, etc.).

12. We have automated tests

We see no meaning in setting a specific coverage goal. The test suite should be sufficient enough that a new developer can make a change. If the tests go green, the build can be shipped to production without any manual verification:

• Unit testing with jest (or Vitest)

• Cypress for feature tests

• All tests shall be able to run on CI

13. Follow the principle of least power

Do not use javascript for something you can solve using css or html. Do not use css for something you can solve with html. Do not use aria for something you can solve with correct semantic html.

14. Use Storybook (or similar "code becomes docs"-tools) to document and isolate our components

15. We create shared libraries for the code that we can share across our applications

When one of our libraries or components seem to be beneficial for other teams than our own, we contribute it to our Core Libraries

16. WCAG compliant

There's more details on this on our dedicated universal design-page.

17. Stored on our CDN

Modern parts of Gjensidige infrastructure run on the Gjensidige Application Platform - or GAP for short. You can reach the team responsible over at Slack on #gap.

Your app should be uploaded to our CDN, it should use a manifest-file that points to each used asset, each asset should be named with a unique pattern for each release/deployment (since our CDN-server will store assets in cache in a very strong way depending on filename).

18. Consider Analytics, Personalization

Gjensidige has many experts within the fields of Analytics and Personalization. Use them to make sure your app is compliant, when relevant. Web apps needs to implement analytics, but also support personalization.