- To run or build the frontend, you'll need to download Node minimum v21 .
- Enable corepack on your machine and download yarn via corepack (don't download yarn globally, it will give you problems at some later point). Follow this guide to download yarn.
Access management has a lot of dependencies, which can get tedious to work with when developing locally. If all you are working with is frontend-specific code (that is, the code found in this repo) then this hybrid solution will simplify your setup, allowing you to run the React application and the BFF (Backend For Frontend) locally, while using the access management backend and other dependencies that are deployed in an AT-environment.
However, it has an additional prerequisit as it will require you to log into your IDE (ex: Visual Studio) with a user that has access to the Keyvault used by test environment AT22.
To get these accesses on your ai-dev user, you need to be part of the following Azure team:
- Altinn-30-Authorization-Test-Developers
Make sure you have the neccecary accesses before proceeding with this setup alternative.
In order to integrate the local code with AT22 in the most seamless way, using the login method, test data, and sdomain-specific tokens, we need to tell the computer when to divert from the the actual AT environment and instead use the localhoast port where our local BFF will be running from.
You can do this by adding following to the host file on your computer:
# Subdomain for accessmanagement
127.0.0.1 am.ui.at22.altinn.cloudYou can find this file in /private/etc/hosts on mac or in c:\Windows\System32\Drivers\etc\hosts on Windows
Remeber to save the host file before proceeding. You might need to flush the dns and clear all cashe in your browser for this change to be set into effect.
Windows:
ipconfig /flushdnsOBS: Note that overwriting this path in the host file will make you unable to reach the true path from your computer, meaning you will not be able to use AT22 to test the currently deployed version of the frontend code. You will still be able to access the other AT environments.
Open Altinn.AccessManagement.UI.sln in Visual Studio (or another IDE).
- In Visual Studio, log in with your ai-dev email (the user that has the necessary accesses)
- Locate the Launch button
- Switch launch settings to the one named LocalDev (If not already chosen)
- Start the application by pressing the Launch button
A browser window will open on the BFFs swagger documentation, this means the launch was successfull.
OBS: These settings use https which requires a certificate to be uploaded or generated by your IDE (the latter is the easiest solution). This might make your browser flag the site as a possible risk the first time you attempt to navigate to it, but it will not stop you from accessing it.
Now that the BFF is running, you can move on to the react app.
Pull the newest version of this repo and navigate to its root
- Run
yarnto install all neccecary dependencies - Run
yarn startto run the application
That's it!
- Open you browser and go to https://info.at22.altinn.cloud/
- Log in using the regular Altinn login (with TestID)
You can now access the regular altinn features enabled in the environment. Once you navigate into a domain that belongs to this repo (am.ui.at22.altinn.cloud), the local code will run instead of the deployed code of this environment.
Happy coding!
The BFF provides us with the option of mocking away all external connections, instead fetching data from static files or generating it dynamically on-call. This can be usefull when testing out code only pertaining to the frontend or when developing functionality that lacks backend support.
The mock can be activated locally or in a specific environment by going to the relevant appsettings file and setting UseMockData to true. Be aware that this should NEVER be done for TT02 or PROD!
"GeneralSettings": {
"FrontendBaseUrl": "https://am.ui.at22.altinn.cloud",
"Hostname": "at22.altinn.cloud",
"UseMockData": true
},Fun fact: The static files used to run the mock is the same that is used for integration tests - meaning we get twice the usage out of the same data! ♻️
Since most of the mocked data is generated from static files, a lot of the functionality will only work for users that are part of the mocked data set. Here is a list of such users and their login details:
-
🍋 Sitrongul Medaljong - fNr: 20838198385
- Covered in all static data with the same IDs as in at22
- Is DAGL for Diskret Nær Tiger AS (310202398)
-
🦢 Intelligent Albatross - fNr: 19895199357
- Used mostly to delegate things to from Sitrongul Medaljong (has the same IDs as in at22)
- Is DAGL for Rakrygget Ung Tiger AS (313523497)
-
🎥 Livsglad Film - fNr: 21915399719
- Used for automatically generated data (performance/worst case testing)
- Partial data coverage (only new amUI)
- Is DAGL for Sta Tom Tiger AS (313160300)
To create a distributable bundle, run yarn build. Environment variables set at build time will be baked into the bundle (e.g. VITE_DEFAULT_LOCALE=en yarn build). See the resulting dist/index.html. If the bundled files are to be served from a path other than the server root, you must pass the --base=/path/to/folder/ argument to yarn build.
pr-labeler action is triggered for each pull request. Based on the branch name, this action adds a label to the pull request. The configuration for the labels can be found here.
The application has a release every wednesday. scheduled-release action is triggered every wednesday 00.00. This action drafts a release, tags the latest package with the release version, f.ex this package has a release version v2023.1. The action drafts the release on different categories. The changes are categorized based on the pull request label. F.ex, A PR with a label bugfix is categorized under bug. The detailed release draft configuration can be found here The deploy in charge for the week, deploys the application to a specific environment(TT02/Prod) using the action deploy-to-environment. The drafted release is then reviewed manually and published by the deploy in charge.
Run yarn to setup code.
Run yarn build to create a build file.
Run yarn test to run cypress tests in browser.
Run yarn coverage to see test coverage stats.
Run yarn lint to run lint checks
Run yarn format to format most of the codebase to set standard in config file
The main entry point is /src/main.jsx. You'll find React components under /src/components/.
The components can be placed 2 ways, either:
If the component's only reusable within a specific feature
features\
featureName\
components\
- ComponentName.test.tsx (unit tests)
- index.ts (public interface for the component)
- style.css (if needed)
Or:
If the components are reusable and being used by other classes
components/
ComponentName/
- ComponentName.tsx
- ComponentName.test.tsx (unit tests)
- style.css (if needed)
Start with these names for your branch depending on what your branch includes.
- bugfix/
- chore/
- test/
- dependencies/
- documentation/
- feat/
- feat/<feature-name>/<issue-number>
- feat/general/<issue-number> (When it's not related to any specific feature. Can also just use feat/ by itself.)
Use PascalCase for component file names.
We use eslint, prettier, typescript, and automatically set up git hooks to enforce these on commits. To avoid confusion, it is recommended to set this up in your IDE.
Install the eslint extension from the marketplace. Configure your IDE to run eslint --fix on save (prettier will also reformat your code when doing this).
Configure your IDE to run eslint --fix on save (prettier will also reformat your code when doing this). It is also recommended to
set up Prettier as the default formatter.
We use standard camelCase for classnames to enable linking of the stylesheets directly and improving simplicity in the process. We separate each Element and Modifier into separate names and use regular css (eks: .accordion.open) to access the combination.
- Sometimes it's needed to restart eslint for it to work properly. E.g. When switching branches, eslint hangs sometimes. To fix this problem in vs code: Do the hot key for workbench.action.quickNaviagtePreviousInFilePicker and run command 'restart eslint server' or restart vs code.
- It's a common problem when writing reducers in rtk; invalid typescript-errors, prettier and lint-errors occurs. To fix this you could try to restart vs code or ignore the error.
You can define stories for components by adding a file with the *.stories.tsx extension.
Start Storybook: Use the following command to start Storybook:
yarn storybookThis project uses MSW (Mock Service Worker) to mock API requests in Storybook. The mock handlers are defined in .mock/handlers.js and the worker is set up in .mock/browser.js.
- For more information on writing stories, see the Storybook Docs.
- To learn about using MSW with Storybook, check out the MSW documentation.