# EDNL LiftStatus Web Components

The EDNL LiftStatus web components for use in web applications.

## Installation

Copy or clone the repo and run `npm install`.

To get live data, you need an access token to put in the `<ls-data>` component inside `index.html`.

### How to get an access token

For the time being, navigate to https://next.liftstatus.nl/ and login. On the left, click on "liften".

In the address bar you can append the url with a lift ID like so: https://next.liftstatus.nl/lifts/31901.

The below Lift ID's are great for testing.

| Lift ID |                      Usefulness                      |
| :-----: | :--------------------------------------------------: |
|  31901  |                Has a lot of movement                 |
|  32386  |                Has a lot of movement                 |
|  32383  |                Has a lot of movement                 |
|  31981  |                Has a lot of movement                 |
|  49234  | Good for testing status messages and has a back door |
|  55040  |           Good for testing status messages           |
|  33137  |           Good for testing status messages           |

Once on the selected elevator page, open the developer tools and navigate to the network tab. From here, filter on WS and select the request to api.liftstatus.nl/socket.io. You can find the token in the headers of this request.

Note: if you do not see a request, you might need to refresh the browser with the network tab open.

### Start developing

Copy the access token and give it as a parameter in the `<ls-data>` component inside of `index.html`.

After that you can run `npm run start` to run the project. It should open to localhost:3000.

## Demo

https://ednl-ls-web-components-demo.web.app/

## UNPKG

https://unpkg.com/browse/ednl-liftstatus-web-components/dist/ednl-liftstatus-web-components/

## Implementation manual (docs)

https://springtree.github.io/ednl-liftstatus-web-components/

To edit it you can run `npm run docs`.

## i18n

- Library: `i18next` (single shared instance in `src/utils/i18n.ts`).
- Supported locales: `nl` and `en`.
- Default + fallback locale: `nl`.

What is translated:
- UI copy and error messages (`ui:*`, `errors:*` in `src/utils/translations.ts`).
- Sensor labels / short labels / mapped sensor values (`sensorLabels`, `sensorLabelsShort`, `sensorValues`).
- Locale-aware formatting used in components (for example percentages and relative time labels).

What is not translated:
- Raw API/socket payload values.
- Status code descriptions from `src/stores/status-codes.json` (used as-is).

Data flow:
- `language` is set on `<ls-data>` (`nl` / `en`).
- `<ls-data>` normalizes it via `getLocale()` and stores it in `store.state.locale`.
- Components read translations through store helpers (`store.t(...)`) and/or locale utilities.
- Components subscribe to locale changes (`watchStoreLocale`), so changing `language` at runtime updates connected components.
- Locale scope is per installation (`id-key`), so multiple instances can run different locales on the same page.

## Naming conventions

We use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary).

Format:
`<type>(optional-scope): <short description>`

Common types:
`build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `revert`, `style`, `test`

Examples:
- `feat(ls-date-picker): add support for selecting custom ranges`
- `fix(ls-data): prevent reconnect loop when token is missing`
- `docs(readme): document local development setup`
- `refactor(store): simplify idKey resolution for publish`