# Shared-UI package

## Purpose

This package contains [React](https://reactjs.org/) components for SideShift UIs.
Used by packages:

- `frontend`
- `widget` (currently widget is in `frontend`)

## Development

### Developing

Scrips for development can be found in `packages.json` as scripts. For development we are using `storybook` which works well with HMR and makes easy to test, develop and maintain UI components. To run use:

```bash
$ yarn workspace @sideshift/shared-ui dev
```

### Testing

Tests are written using `jest` and `testing-library`. To run tests use:

```bash
$ yarn workspace @sideshift/shared-ui test
```

### Linting

Linting rules are the same as `frontend` package have. To run linter use:

```bash
$ yarn workspace @sideshift/shared-ui lint
```

### Building

For building the project, we are using `rollup` instead of `webpack` (See `Architecture` section). To build project run:

```bash
$ yarn workspace @sideshift/shared-ui build
```

## Best practices

- Try to keep dependencies as few as it's possible. Relying on 3rd party code can slow down development since we need to track updates and be sure they not breaking anything. Dependencies also can introduce security issues.
- Try to write general components, don't use business logic and keep them independent from other packages and layouts.

## Additional info

### Architecture

The package tries to manage it's own dependencies independently from the monorepo. For generating configs `yarn workspace @sideshift/tools monorepo-update` is used as well as in other packages, but configs are trying to not extend anything. This can help us to develop faster and separate it easily once we want to. The project uses [Rollup](https://rollupjs.org/) instead of [Webpack](https://webpack.js.org/) because it's [better](https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c) [for building](https://medium.com/@PepsRyuu/why-i-use-rollup-and-not-webpack-e3ab163f4fd3) libraries.

### Plans

We should use components from here wherewer we can. Once we are starting to separate `widget` from `frontend`, it should build it's UI based on this package. Also we can build new (or while refactoring) `frontend` UIs using this package.