Skip to content
Snippets Groups Projects
Select Git revision
  • main default protected
  • OZG-7324-license
  • OZG-7324-license-header
  • release
  • 1.4.0
  • 1.3.1
  • 1.2.0
  • 0.4.0
  • 1.0.0
  • 0.9.0
  • 0.3.2-alpha
  • 0.3.1-alpha
  • 0.0.3-alpha
  • 0.0.2-alpha
  • 0.0.1-alpha
15 results

antragsraum-client

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    OZGCloud authored
    01a0af82
    History
    Name Last commit Last update
    client
    .gitattributes
    .gitignore
    Jenkinsfile
    README.md

    OZG Frontend

    The front end project for the OZG cloud.

    Quickstart

    Runs all the build scripts in antragsraum-client/client folder

    $ npm install
    $ npm run build

    And start the development server:

    $ npm start

    Docker build ozg-frontend-client locally

    (Ensure, Docker daemon is running)

    cd /client/docker
    $ docker compose up

    Docker build ozg-frontend-docs (Styleguidist) locally

    (Ensure, Docker daemon is running)

    If you only need to run the docker container without all the build steps:

    cd /client/docs
    $ docker compose up

    Run the CSS regression tests

    The CSS tests run with BackstopJS. This framework compares the snapshots from a running URL against some reference images. The references are saved in **client/backstop/backstop_data/bitmaps_reference **.

    At the moment we test the desktop and mobile view of the styleguidist component documentation page. So before running the CSS regression tests you need to first run the component docs:

    $ npm run styleguidist

    And then run the test css script:

    $ npm run test:css

    This will start a docker container with a headless browser. If it fails you need to check in the directory * client/backstop/backstop_data/bitmaps_test* and find in the last directory the failed diff.

    If the change was intentional you can update the references with the following script:

    $ npm run backstop:approve

    Available NPM Scripts

    In the client directory, you can run:

    npm start

    Runs the app in the development mode.
    Open http://localhost:8082 to view it in the browser.

    The page will reload if you make edits.
    You will also see any lint errors in the console.

    npm run build:typescript

    Compiles the TypeScript files into JavaScript and stores the result in the build folder.

    npm run build:webpack

    Runs Webpack to create the deployment artefacts for the application in the /dist folder.

    npm run test:unit

    Launches the test runner in the interactive watch mode.
    See the section about running tests for more information.

    npm run test:e2e

    To open the Cypress to create and run e2e test.

    npm run check

    Runs all the checks

    npm run check:prettier

    To run prettier find format problems with your JavaScript code.

    npm run check:lint

    To run eslint find and fix problems with your JavaScript code.

    npm run prettier:write

    To run prettier to format the sources.

    npm run styleguidist

    To run the styleguidist component documentation server.
    Open http://localhost:6060 to view the documentation.

    npm run styleguidist:build

    To build the styleguidist artefacts under the /styleguide folder.

    npm run test:css

    Runs the CSS regression tests (see bellow for more details).

    npm run backstop:approve

    Updates the CSS regression test references according to the last test result (see bellow for more details).

    Environment configuration

    There are two types of env configuration variables:

    • ones set via an .env file/manually setting environment variables that are read at compile-time with fixed values afterwards (or alternatively read at startup of the Webpack dev server for development purposes). There is a whitelist in webpack.config.js that makes sure that only the specific environment variables we actually use are passed to the application. Currently defined variables are the following:

      • NODE_ENV: should be either "production", "development" or empty (which then assumes "development") to activate/deactivate features that should only be available in a dev build
      • PROJECT_NAME: set by Webpack and is shown in version info
      • PROJECT_VERSION: set by Webpack and is shown in version info
      • ANTRAGSRAUM_HOST: the base URL of the Antragsraum API if the Webpack dev server is used
      • INFO_MANAGER_HOST: the base URL of the Info Manager if the Webpack dev server is used
    • ones set via an env.js file. These are environment variables that should be configurable at run time. These are the following:

      • REDIRECT_URL: The URL where the login entry point is located. For use with BayernId this should be something like '/antragsraum/saml2/authenticate/bayernid'. When using with BayernId this must match the entry in the metadata document send to Akdb. For local dev use this value must be '/antragsraum/login'.
      • LOCALE_BUTTON: if set to "true", show a button on the overview page that toggles the language between German and English (to demonstrate the currently available localisation features)

    Running with a local backend

    To run the frontend alongside a locally running backend, you need to set the respective env variable so that the backend can be found by the frontend:

    ANTRAGSRAUM_HOST=http://localhost:8080

    You need to start the backend according to the documentation in antragsraum-server. The most simple way to get a working backend with mocked data is to run the backend in standalone mode.