We're excited that you're thinking about contributing to Sprintly-UI. In order to make contributing as friction-free as possible, please read through and consider the following guidelines.
Please refer to the roadmap before starting work on new components that you plan for inclusion in this repo. This will help us avoid duplicate efforts. If there's something that we're already planning via the roadmap that you would nevertheless like to work on, we'd be excited to collaborate with you on it.
If there's a feature that you'd like to see as a component that isn't on the roadmap, have at it! We'd prefer if you filed an issue before starting work so that we can check in and see if there's anything we can help with, but it's really up to you.
Since we would like to be as non-deterministic as we can about how these components will be used, the assumption that we make is that users of this library will be plugging these componenets into apps that contain parent (or "controller") views that will manage data fetching and syncing themselves.
Designing components for maximum reusability isn't always easy, especially when writing multiple components with the intention of combining them to form a composite component, like our SortableTable. A good rule of thumb is that if you think there could be another use for one of the components within your composite component, see if you can reasonably break it out (ie, make it functional for your situation while making its imputs as generic as possible). That's not always possible for very domain-specific components, so just use your best judgement.
To support React's one-way data flow pattern, we ask that you try to avoid state wherever possible when developing components for inclusion in Sprintly-ui, and instead favor passing data and callback functions through as props. The React getting started docs are great and go over one-way data flow and the difference between props and state in detail.
We're using LESS to generate styles and have a build task for compiling minified and unminified versions: $ npm run build-css. Compiled styles will be saved to /dist/css.
All PRs must include unit tests, and we ask for a minimum of 80% coverage. Tests are written in Mocha, Chai, and Sinon, and we use Istanbul for code coverage. We recommend using the React Test Utilities, which make testing component lifecycle much easier.
Please include documentation and an example file as part of any PRs for adding new components.
You can find examples for existing components in /examples. If an appropriate example file doesn't exist for the category of component you've developed, please add a new (appropriately named) file. There's a template file that you can copy over to use as a base. Don't forget to add a link to your example file in the examples index!
All component documentation is located in the docs folder. Please update the docs, adding a new doc file if one covering the category your new component belongs to isn't already represented.
When you are ready to submit your request, please copy over the PR template into the body of your pull request and fill it out. This gives us a common format for reading and reviewing pull requests. For more info on how PR templates have enhanced our workflow at Quick Left, see this blog post by Justin Abrahms.
If you're on the Sprintly/Quick Left team and you're merging code, be sure to bump versions in package.json before publishing to npm via $ npm publish. Also be sure to tag the commit $ git tag <new-version-number> (or just use the GH tagging interface in the 'releases' tab) before running the script to install the latest CSS in our S3 bucket via $ ./upload-assets-to-s3.sh.