Frontend Coding Guidelines

Project and folder structure according to this article

CSS class names:

• according to BEM

• in the SCSS files, use selectors like & instead of writing class names in full length (see this article)
  example: toolbar { … &__buttons { … } } instead of toolbar { … } toolbar__buttons { … }

Structure HTML files with sections and separate them with comments: <!-- <section name> -->

Use RxJS operator take(1) instead of first()

In the state, we have to use take(1) whenever we get an observable from a function we call

Our store’s actions always return observables (no void)

Use lambda function instead of .bind(this)
example:

• ret.children.map(children => this.classificationsDeepCopy(children));
  instead of
  ret.children.map(this.classificationsDeepCopy.bind(this));

We use ExampleType[] instead of Array<ExampleType>, when refactoring or writing new code

Test name pattern: should_ExpectedBehavior or should_ExpectedBehavior_When_StateUnderTest depending on the specific test

Testing standards according to this article

All entities (displayed in the UI) should start with a capital letter

How to write TASKANA specific words which are displayed in the UI:

• Entities: White spaces instead of camel case, all words start with a capital letter
  e.g. WorkbasketAccessItem → Workbasket Access Item

• Instance variables: White spaces instead of camel case, all words start with lower case in continuous text and with capital letter otherwise (e.g. in captions)
  e.g. in continuous text: <Classification>.serviceLevel → service level
  e.g. in a caption: <Classification>.serviceLevel → Service Level

For maps, we recommend to use ‘valueByKey’ naming convention