|
1 |
| -# Precise UI |
| 1 | +# <img src="docs/assets/precise-logo.svg" width="240"> |
2 | 2 |
|
3 |
| -[](https://travis-ci.org/ZEISS/precise-ui) |
| 3 | +[](https://zeissgroup.visualstudio.com/DCC/_build/latest?definitionId=1073?branchName=master) |
| 4 | +[](https://travis-ci.org/ZEISS/precise-ui) |
4 | 5 | [](https://www.npmjs.com/package/precise-ui)
|
5 | 6 | [](https://www.npmjs.com/package/precise-ui)
|
6 |
| -[](https://github.com/ZEISS/precise-ui/releases) |
7 |
| -[](https://github.com/ZEISS/precise-ui/issues) |
8 |
| -[](https://cla-assistant.io/ZEISS/precise-ui) |
| 7 | +[](https://github.com/ZEISS/precise-ui/releases) |
| 8 | +[](https://github.com/ZEISS/precise-ui/issues) |
| 9 | +[](https://cla-assistant.io/ZEISS/precise-ui) |
9 | 10 |
|
10 |
| -## License |
| 11 | +A complete opinionated React component library with minimal dependencies powered ZEISS. |
11 | 12 |
|
12 |
| -Precise UI is released using the MIT license. For more information see the [license file](LICENSE). |
| 13 | +The UI component library contains both, very low-level design elements as well as combined high-level design elements. In general, the intention of the library is to simplify development by exposing components that satisfy design specifications and provide ease of programming. Repeatable UI designs should therefore only take minutes instead of hours. |
| 14 | + |
| 15 | +See [https://precise-ui.io](precise-ui.io) for our kitchen sink (i.e., demo page illustrating all the components incl. their documentation). |
| 16 | + |
| 17 | +## Getting Started |
| 18 | + |
| 19 | +Basically, common usage should be implicit while flexibility is provided by explicit statements. As such we aim for (opinionated) simplicity, while being able to customize as much as possible. Even though the standard design is pretty much set for our own primary target, we want to achieve full freedom in that area. For this reason we are constantly improving how we do theming and how to expose components to enable any sort of customization that may be desired. |
| 20 | + |
| 21 | +Precise UI can be easily integrated in your frontend project by using npm or yarn. To start using it, please follow the instructions below: |
| 22 | + |
| 23 | +### Installation |
| 24 | + |
| 25 | +1. Firstly, you have to install it: |
| 26 | + |
| 27 | +```sh |
| 28 | +npm i precise-ui |
| 29 | +``` |
| 30 | + |
| 31 | +or alternatively, using yarn |
| 32 | + |
| 33 | +```sh |
| 34 | +yarn add precise-ui |
| 35 | +``` |
| 36 | + |
| 37 | +2. Then, make sure that you have also all peer dependencies installed: |
| 38 | + |
| 39 | +```sh |
| 40 | +npm i react styled-components |
| 41 | +``` |
| 42 | + |
| 43 | +### Usage |
| 44 | + |
| 45 | +Everything ready, now you can start importing precise-ui componenets. |
| 46 | + |
| 47 | +```jsx |
| 48 | +import { TextField } from 'precise-ui'; |
| 49 | + |
| 50 | +<TextField label="Label" /> |
| 51 | +``` |
13 | 52 |
|
14 |
| -## Issues |
| 53 | +You can see a list of all available components on our [website](https://precise-ui.io/). |
15 | 54 |
|
16 |
| -When creating a new Issue, please use one of the provided templates: |
| 55 | +## Contributing |
| 56 | + |
| 57 | +Everyone is welcome to make any contribution on Precise UI. However, before you start, make sure you read our [Contribution](/.github/CONTRIBUTING.md) instructions. |
| 58 | + |
| 59 | +If you feel uncertain whether you should contribute or not maybe our [code of conduct](CODE_OF_CONDUCT.md) can help you. |
| 60 | + |
| 61 | +### Issues & Support |
| 62 | + |
| 63 | +If you have any usage and general questions, you are welcome to ask a question on **Stack Overflow** using the tag `precise-ui`, and you will receive help as soon as possible. |
| 64 | + |
| 65 | +Also, when creating a new Issue here, please use one of the provided templates: |
17 | 66 |
|
18 | 67 | - [Bug Report](https://github.com/ZEISS/precise-ui/issues/new?template=bugs.md)
|
19 | 68 | - [Feature Proposal](https://github.com/ZEISS/precise-ui/issues/new?template=features.md)
|
| 69 | + |
| 70 | +### Development |
| 71 | + |
| 72 | +The following sections guide you through the process of developing Precise UI. |
| 73 | + |
| 74 | +#### Installation |
| 75 | + |
| 76 | +For development you will need NPM and Node.js 8+. After cloning the repository install all dependencies via |
| 77 | + |
| 78 | +```sh |
| 79 | +npm install |
| 80 | +``` |
| 81 | + |
| 82 | +Here is a quick example to get you started. All you need is to run: |
| 83 | + |
| 84 | +```sh |
| 85 | +npm start |
| 86 | +``` |
| 87 | + |
| 88 | +As a result this will start the development server running the kitchen sink (our demo application), which runs locally and can be reached via [localhost:6060](http://localhost:6060). Note: this port can be changed. The available page contains all included components and some hopefully useful documentation for these. |
| 89 | + |
| 90 | +#### Versioning |
| 91 | + |
| 92 | +Incrementing the version can be done via `npm` as well. |
| 93 | + |
| 94 | +```sh |
| 95 | +npm version |
| 96 | +``` |
| 97 | + |
| 98 | +This will show the current version and ask for a new version. As a result the information in the package.json is updated. Additionally, a git tag is created with the information (automatically prefixed using a "v"). The process could also be automated, e.g., by specifying the new version directly. So, for instance if our new version is "1.2.3" we just use the following command: |
| 99 | + |
| 100 | +```sh |
| 101 | +npm version --new-version 1.2.3 |
| 102 | +``` |
| 103 | + |
| 104 | +#### Conventions |
| 105 | + |
| 106 | +We do not use default exports. Instead, every export should be named properly. For components, the name of the export equals the name of its file or folder. |
| 107 | + |
| 108 | +**Folders** |
| 109 | + |
| 110 | +Every exposed main component has to be placed in its own folder below `components`. Components placed in `*.part.tsx` files are considered internal components only created for providing some (necessary) internal structure. |
| 111 | + |
| 112 | +Every exposed design helper component has to be placed in a file in the `quarks` folder. Design helpers do start with a `Styled` prefix, just like plain styled components should be. |
| 113 | + |
| 114 | +Any higher-order component (HOC) should be located in the `hoc` folder. The naming convention is to expose the HOC with a `with` prefix. |
| 115 | + |
| 116 | +The context related components are located in the `contexts` folder. |
| 117 | + |
| 118 | +Plain functional utilities have to be placed in the `utils` folder. Even though for convenience all contents of utils are exported, their modules should be referenced directly from any components. The utilities have to be pretty much self-sustained, i.e., referencing back components is forbidden. |
| 119 | + |
| 120 | +**Namings** |
| 121 | + |
| 122 | +While *stateless* components should be created as a `const`, *statefull* components should be created as a `class`. In the former case only an interface with the component's name suffixed with `Props` should be created (to declare the typings of the props). In the latter case an additional interface with the component's name suffixed with `State` should be created, too. This interface carries the type information for the internal state of the component. |
| 123 | + |
| 124 | +Input field components should always be suffixed with `Field`. Their props should extend the `InputProps` interface. |
| 125 | + |
| 126 | +Event props should be prefixed with `on` and they should have a single argument only. This argument must be an object that follows an interface, which has an adequate name for the event, usually consisting of the component's name, the event type, and being suffixed with `Event`, e.g., for `onChange` of a `TextField` we have `TextFieldChangeEvent`. |
| 127 | + |
| 128 | +We have a variety of different component classes. We should be able to easily distinguish between the different classes of components by looking at the suffix of a component. We have: |
| 129 | + |
| 130 | +- `*Control`, stateful functional components |
| 131 | +- `*Panel`, layout to be used |
| 132 | +- `*Field`, an input field |
| 133 | + |
| 134 | +Exceptions to this convention can occur due to various reasons (historical, aesthetic, ...), but should always be reasoned and discussed properly. |
| 135 | + |
| 136 | +#### Code Formatting |
| 137 | + |
| 138 | +There is not much to write. We use prettier and our build checks if the code has been properly prettified. Just run |
| 139 | + |
| 140 | +```sh |
| 141 | +npm run prettier |
| 142 | +``` |
| 143 | + |
| 144 | +if you are in doubt that your code changes fits our desired formatting. |
| 145 | + |
| 146 | +#### Unit Tests |
| 147 | + |
| 148 | +Any change needs to be in company with its respective unit tests. In order to run the tests we use the following command: |
| 149 | + |
| 150 | +```sh |
| 151 | +npm run test |
| 152 | +``` |
| 153 | + |
| 154 | +This will also run the linter. The standalone unit tests are available via `test:unit`. Likewise, we can also easily report the code coverage: |
| 155 | + |
| 156 | +```sh |
| 157 | +npm run test:unit --coverage |
| 158 | +``` |
| 159 | + |
| 160 | +For unit tests we use Jest. We recommend using snapshot tests (which are done via enzyme and some JSON snapshot serializer). |
| 161 | + |
| 162 | +#### Adding new icons |
| 163 | + |
| 164 | +The list of all imported icons is in `/tools/icongen.config`. After modifying the list you should run `npm run icongen` or it will be run on prepush. |
| 165 | + |
| 166 | +## License |
| 167 | + |
| 168 | +Precise UI is released using the MIT license. For more information see the [license file](LICENSE). |
| 169 | + |
| 170 | +We are using some icons from [Material UI Icons](https://github.com/mui-org/material-ui/tree/master/packages/material-ui-icons). Their code and design is covered by the respective license of [Material UI](https://github.com/mui-org/material-ui) (MIT). |
0 commit comments