roomle-ui v3.0.2

Roomle UI

This project provides the UIs on top of the Roomle Web SDK (https://github.com/Roomle/web-sdk). It will be constantly developed and maintained by the Roomle Web Team since it's the official user interface of the Roomle web components and standalone version (e.g: https://www.roomle.com/t/configurator/).

Which UIs are in this repository:

• Configurator
• Planner
• GLB-Viewer

Techstack:

• Vue (Vuex)
• Typescript
• Jest
• Cypress
• Babel

Project setup

yarn install

Compiles and hot-reloads for development: yarn run serve

Compiles and minifies for production yarn run build

Run your tests yarn run test

Lints and fixes files yarn run lint

Run your end-to-end tests yarn run test:e2e

Run your unit tests yarn run test:unit

Project structure

• /public
  • /translations
• /src
  • /common
    • /assets
    • /components
  • /configurator
    • /assets
    • /components
    • /store
  • /planner
  • /glb-viewer

Public directory (/public)

These assets will simply be copied and will not go through webpack. Need to be referenced via absolute paths.

Translations (/public/translations)

Default folder for LocalTranslationSource (src/common/translations/local-translation-source.ts)

Source directory (/src)

Consider to read the Vue style guide first before changing files in those directories: https://vuejs.org/v2/style-guide/

Common (/src/common)

Contains all components common to all UIs.

Configurator (/src/configurator)

All files related only to the configurator, see https://www.roomle.com/t/configurator/

Assets (/src/*/assets)

Files placed here need to be imported in JavaScript or referenced in templates/CSS via relative paths. Such references will be handled by webpack.

Components (/src/*/components)

This directory contains all Vue single component files (https://vuejs.org/v2/guide/components.html).

Vuex Store (/src/*/store)

Contains all files related to Vuex: https://vuex.vuejs.org/guide/

Guidelines

Store

Only access the store from templates in a reading manner. Never dispatch actions or commit mutations from within the template.

If something is local to only this specific component it's ok to store this state inside the components instance but always be aware that we need to be able to hot-swap components which means that a component for mobile UI could be replace by a component for desktop UI but the hot swapped component needs to know where the other component stopped and from where to continue. Therefore there are only some cases where we do not need to store the state in the global state tree.

We try to limit boilerplate code therefore we want to be lean on the distinction between a mutation and an action. As a general rule of thumb we decided to do simple state changes in mutations. As soon as complexity grows we create actions. Example for when to use actions:

• we need to change multiple properties of the store
• we need to change the store in an async way