# Front Row Seat Integration Library
> 🏌️‍♀️ 🤼‍♀️ 🎾

A web based library for handling the integration of the event centres with sportsbooks.
The library will initially be tasked with handling the communication between sportsbooks and the event centres app.
These communications will predominately be for UI synchronisation, ie. bet slip selections being mirrored in both UIs.

```bash
npm i @img-arena/front-row-seat
yarn add @img-arena/front-row-seat
```

## Contributing
```bash
yarn
yarn start:dev
```

### Considerations
* changes should be backwards compatible with older versions of the event centre that are using older versions of front-row-seat.js
  * if this is not possible, a solid migration plan must be agreed with the rest of FRS
* avoid using dependencies or polyfills that might pollute the global scope (ie: @babel/preset-env) as this has been raised as a security warning by our clients

## Testing
There are both unit tests and some integration tests. The testing of iframe's in JSDOM is complicated but possible, so
as it stands cypress is being used to test the iframe side of things (`postMessage`).

**Note:** you'll need to run the dev build each time you run the tests, as the unit tests are using the dist build folder.

To run the unit tests:
```bash
yarn test:unit
```

### Integration tests

Start the test site servers (in different consoles), then run the tests:
```bash
# terminal one
yarn start:test-site

# terminal two
yarn start:test-site-2

# terminal three
yarn cy

# or you can open the Cypress UI to watch the browser automation run:
yarn cy:open

```

## Debugging

To debug the communication between the parent and the child iframe, you can set the `__debug__` property to true when
initialising an event centre or Betlink instance. This will log all messages sent and received along with any other logs that are added.

example:
```js
const eventCentre = eventCentre({
    ...,
    __debug__: true,
})
```

## Publishing

The package is automatically published to the npm registry when PRs are merged to master, the version changes are based on commit message syntax; see below.

## Commit Style

This repo follows the [Conventional Commit](https://www.conventionalcommits.org/) format. This is so that we can automatically figure out what the SemVer release tag should be. Note that commits must be in this format, we use Husky to enforce this.

```bash
$ git commit -m "feat(frs-123): added some super cool feature"
```

Commits and SemVer tags are directly linked, if you want a commit to not be evaluated in whether or not the semver version should change, add " [skip ci]" to the end of the commit message - https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/.

### Commitzen

This repo is Commitzen compatible, if you wish to use it instead of writing the commit via `git commit -m ...` try `cz` after `git add`.

https://github.com/commitizen/cz-cli#installing-the-command-line-tool