@kushki/ng-suka/README.md

<p align="center">
  <h1 align="center">Suka Components Angular</h1>
  <p align="center">
    An Angular implementation of the Suka Design System
  </p>
</p>

### Getting started

Assuming we're starting with a new @angular/cli project:

```shell
$ npx @angular/cli new my-project --style=scss
$ cd my-project
$ npm i --save @kushki/ng-suka
```

Then we need to include suka components in `src/styles.scss`:

```scss
@import '~@kushki/ng-suka/scss/main';
```

That's it! Now we can run `npm start` and start building out our application!

[![Storybook](https://cdn.jsdelivr.net/gh/storybookjs/brand@master/badge/badge-storybook.svg)](https://kushki.github.io/ng-suka/)

[![Edit Carbon Components Angular](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/suka-angular-playground-jrjns)

### Contributing

#### Quickstart
- fork Kushki/ng-suka and clone it locally
- run `npm install` to grab all the dependencies, then `npm run storybook` to start storybook
- **if you are adding a component**:
  - add a folder with your component code, styles, tests and story under `projects/suka/src`
  - export your module from `public-api.ts`
- **if you are contributing a fix**:
  - add your fix, update the documentation as needed
  - consider adding or modifying a test case to cover the fix
- follow the [Angular style guide](https://angular.io/styleguide)
- be sure to run `npm test` and `npm run lint` to make sure the tests and linter pass
- submit a PR

#### npm commands
To keep our build dependencies local we use npm scripts to run our webpack, gulp, and general build tasks. You should never install webpack or gulp globally as that will likely conflict with our version. You should never need to modify the build process to add a component or story.
- `npm run storybook` to run storybook (port 6006)
- `npm run build` to generate the dist
- `npm run lint` to run tslint
- `npm test` to run tests

### Philosophy
- Components should be the smallest unit of computation
  - Think in terms of pages and applications composed from a multitude of components rather than pages or applications as a single unit of computation
- Components should delegate to the consumer whenever possible
  - The individual applications should be the single source of truth, and be able to create any UI from our building blocks
- Components should do one thing, and do it well
  - This does not mean they should be over specialized, but rather focus on providing a single, core experience
- Components should NOT maintain more state than absolutely necessary
  - Likewise, stateless components should be favored whenever possible
- Components should NOT *necessarily* implement the style guide point-for-point, the guide simply provides guidance on overarching functionality, components should enable that and product specific designs **without** baking in extra functionality