|
| 1 | +# Contributing |
| 2 | +If you got here it means you want to dedicate some of your time and help us improve this library. |
| 3 | +So first of all, thank you ❤️ |
| 4 | + |
| 5 | +When contributing to this repository, please first discuss the change you wish to make via [issue](https://github.com/wix/react-native-ui-lib/issues/new/choose), |
| 6 | +[Discord channel](https://discord.gg/2eW4g6Z), or any other method with the owners of this repository before making a change. |
| 7 | + |
| 8 | +## Pull Request Process |
| 9 | + |
| 10 | +1. First make sure the environment is working and synced with master. For installation details go [here](https://github.com/wix/react-native-ui-lib/blob/master/markdowns/getting-started/setup.md#demo-app) |
| 11 | +2. Before submitting a PR we suggest running `npm run prepush` command that verifies our lint, TS and tests were not broken. |
| 12 | +3. Please use our PR prefixes accordingly. `fix` for bugfix, `feat` for feature, `infra` for infrastructure changes and `docs` for documentation related changes (e.g `fix/ButtonStyle`, `feat/Avatar_colorProp`) |
| 13 | +4. Please don't change our PR template. |
| 14 | + - In the Description section add everything that can help the reviewer and the reviewing process, like a description of the issue and the way you decided to go about it, screenshots or gifs, etc. |
| 15 | + - The Changelog section is important. Write a message for the library users - this message will be included in our release notes. |
| 16 | +5. We try to make the PR review process as quick as possible, please be patient |
| 17 | + |
| 18 | + |
| 19 | +### Code Standards |
| 20 | + |
| 21 | +- Readability and clean code above all - we believe a clean code is easier to maintain and refactor when needed. |
| 22 | +- Deciding on an API is not trivial but we always aim to keep it generic and intuitive - feel free to consult with us. |
| 23 | +- Our documentation is derived from our components' prop comments, make sure to add a clear description when adding new props. |
| 24 | +- When possible, consider adding tests for the new functionality you added. |
| 25 | +- Try separating logic from UI as much as possible using hooks and presenters. |
| 26 | +- Keep components small and single purposed. |
| 27 | + |
| 28 | +#### Controlled vs Uncontrolled components |
| 29 | +When facing a new component's API we usually aim for making it controlled. |
| 30 | +This is in order to give the user most control over what will be rendered in the component. |
| 31 | +Having said that, keep in mind that in some cases (mostly due to performance concerns) we decide on making a component uncontrolled. |
| 32 | + |
| 33 | + |
| 34 | + |
| 35 | + |
| 36 | +## Typescript Status |
| 37 | +Currently most of our code is migrated to typescript though we still have some leftovers of javascript code and manual typings. |
| 38 | +Until we complete the migration you are required to do the following for new TS files |
| 39 | + |
| 40 | +Before pushing new code make sure to run `npm run build:dev` - this check for TS errors and create appropriate declarations (`d.ts`) files under generatedTypes folder. Make sure to push these files as well! |
0 commit comments