• Install dependencies

    $ yarn install
  • Runs the project:

    $ yarn start
  • Runs the mock server:

    $ yarn mock
  • Runs the application server:

    $ yarn serve
  • Packages a deployment version of the application:

    $ yarn build
  • Runs unit tests:

    $ yarn test
  • Runs unit tests with coverage:

    $ yarn test --coverage
  • Runs unit tests for CI purpose

    $ yarn test:ci


The project implements styled-components to manage component styles.

All component folders contain a __styles__ directory for styling files.

The style guide is defined in src/__theme__/theme.js: All design facets of the application are referenced and used throughout the app by using the ThemeProvider component provided by styled-components.

Unit tests

The project uses jest as a test runner and expectation library, and react-testing-library as a testing framework. JSX tags contains as often as possible a data-testid attribute to retrieve the element through the DOM. API calls are mocked with jest-fetch-mock.


A mock server is run when the app is started with the start script. It allows to mock API routes by providing a custom response. Check mocks/index.js to see a working example.

The mocking management uses mockyeah

Code splitting

The project implements redux-dynamic-modules to dynamically load pages workflow (actions/reducers/sagas). Page components are loaded using Suspense and lazy React modules.


Localization is provided by react-i18next

i18n is supported out of the box.

International contents are stored in src/assets/locales. Keys can’t be modified.

The language must be expressed with a two-chars code (“fr”, “en”, …)

Language setting

The interface language is retrieved following this order:


Team Conventions

This application is co-maintained by all front-end developers at La Javaness. Each contribution must follow established conventions.

We ensure consistent code formatting with Prettier, code quality with ESLint, and commit message formatting with commitlint.

Incoming code must not cause existing tests to fail; that rule is enforced with a precommit hook.

Code should be pushed to a feat/* or fix/* branch based on the type of change made, and a Pull Request made against the develop branch. A fellow developer must approve the PR before it can be merged.



The project uses semantic-release to upgrade, document and deploy its NPM package, and commitlint to ensure all commit messages are understood by semantic-release.

Please read the upstream documentation to understand the enforced format. Below is an excerpt for quick reference:

Commit message Release type
fix(pencil): Stop graphite breaking when too much pressure applied Patch Release
docs(README): Append a Use graphite properly section to README Patch Release
refactor: Improve ‘graphiteWidth’ option Patch Release
style: Remove all semi-colons Patch Release
feat(pencil): Add ‘graphiteWidth’ option (Minor) Feature Release
perf(pencil): Remove graphiteWidth option (Major) Breaking Release
BREAKING CHANGE: The graphiteWidth option has been removed. (Major) Breaking Release

Below is the meaning of the different commit prefixes:

  • feat: (new feature for a component or new component)
  • fix: (bug fix in a component)
  • docs: (changes to the documentation)
  • style: (formatting, missing semi colons, etc; no production code change)
  • refactor: (refactoring production code, eg. renaming a variable)
  • test: (adding missing tests, refactoring tests; no code change)
  • perf: (changes to code for performance reasons)
  • chore: (updating yarn tasks, CI pipelines, build scripts, etc; no code change)

Precommit Hooks

Both test:ci and prettier commands are run before each commit to ensure the code remains well-formatted and tested.

Ensure the `.git/hooks/pre-commit“ file is present in your repository.

The yarn prettier command used by pre-commit hooks automatically fixes style issues and stages any unstaged content into your commit, to make sure those style changes are staged. This prevents the use of partial commits. If you want to commit only part of your changed files, you can stash unstaged code before committing. This is the preferred way of doing things at La Javaness.

Technical overview

Login with keycloak

Admin panel setup

Visit localhost:8080 in development to access keycloak admin panel.

To manage session time, you might consider changing the following values:

  • SSO Session Idle (in Realm Settings/Token): default refresh token lifespan
  • SSO Session Max in (Client/clientName/Settings – advanced settings): session max time
  • Access Token Lifespan: lifespan of token used for request authentification.

For security purpose, it is adviced to keep Access Token Lifespan short and rotate it with the refreshToken. refreshToken value is bound to the lowest of the two values SSO Session Idle and SSO Session Max. Check stackoverflow for further details

You should note that user is logged out when refreshToken is outdated.

To allow session to be persisted, you have to enable remember me in Realm Settings/Login

Config files

Keycloak is initated thanks to keycloakConfig object. Default clientId and realm are annotto . You can update these values in a .env file.

Please note that the param url has to be the exact same one as the one setup on the backend.

For more config options, please check keycload.js adapter documentation.


View Github