Conventions

Convention over configuration

Design paradigm

Convention over configuration (also known as coding by convention) is a software design paradigm used by software frameworks that attempts to decrease the number of decisions that a developer using the framework is required to make without necessarily losing flexibility.

Components

Our component collection provides a lot of conventions. We use element-ui (opens new window) for all other elements (e.g. Input, Radio, etc.)

Linters

We have conventions for writing our code. They are written into a custom config for eslint: @jdi/eslint-config-standard (opens new window) and @jdi/eslint-config-vue (opens new window). We also have a prettier config (opens new window) so that our code "looks" the same.

Composables

We strive to separate reusable code into composable. Unfortunately, the composition API is newer than our backoffice, so not all code is in a composition (yet).

Translations

Based on the useEntity composition the current entity is determined. This is (most of the time) the same as the prefix for the Page component.

WARNING

All entities will be ported to a singular-form. So for example when you pass down computers it will automatically make it computer.

Status codes

We have conventions for status codes.

Methods

We do have conventions for request methods.

Data structures

We do have a few conventions for fetching data.

Releases

Releases are done via the Semantic Release principle. We're linting our commit messages with lint-staged (opens new window) and have to comply with semantic-release-standards (opens new window)

TIP

Read more about semantic-release and commitlint in our @jdi/semantic-release-config-standard-repo (opens new window) or @jdi/commitlint-config-standard-repo (opens new window).

Alpha releases

If a customer project needs a change to the vue-backoffice-library but no other project changes, the update can be merged into a development branch which will trigger an alpha release. After installing the alpha release in the customer project, it can be tested locally or on the test environment. If the test is successful, install the stable release.

Read more about channels

Testing

Tests are done with either jest (in combination with vue-test-utils) or cypress. We don't strive towards 100% code coverage, but we do want to encourage to extensively test edge-cases of difficult methods in your code.

You can run the following command to see your test results:

$ yarn test --coverage

TIP

We have specific rules for writing tests in @jdi/eslint-config-standard (opens new window) and in @jdi/eslint-config-cypress (opens new window). Those rules are based on eslint-plugin-jest (opens new window) eslint-plugin-no-only-tests (opens new window) and eslint-plugin-cypress (opens new window)