ddunkin/styled-ui

Faithlife UI styleguide and set of components

Styled UI

View Demos Here

How to contribute

• File an issue first describing what you'd like to change, or check with one of the maintainers before doing any work to ensure you are headed in the right direction
• Clone this repository locally.
• Install NodeJS
• Install Yarn
• From a terminal, run these commands from the project directory
  • yarn to restore packages
  • yarn build to build webpack
  • yarn catalog-start to start the development environment
  • yarn precommit to fix style errors before committing
• When you're ready to commit your work, create a new branch for your contribution, and then sync your branch with Github
• Open a pull request via the Github Web UI to request review

How to publish

• Update VersionHistory.md.
• Run yarn version, following semantic versioning when choosing the new version number.
• Push your changes to master.
• Go to this Jenkins build page and click "Build".

Why?

This project addresses problems introduced by creating components from scratch. Often a component from spec gets implemented multiple times, either from Zeplin or forked from an existing control. Each time an implementation happens, inconsistencies are introduced. It's also harder to introduce animations and shadows after the prototype has been built. By using reference components instead, there's a much higher chance the final products will the contain all margins, animations, and hover states the design calls for.

Goals

• Components in this library must be built with Styled Components + React. Large additional runtime libraries should not be added such as moment, but tiny dependencies like lodash.debounce are OK.
• UI components should support basic color theming and should have a variation documented that demos an alternate theme.
• UI components are simple. For complex components (such as a sortable list control with inline search), consider creating a reusable component in a separate project
• Style modifications should be approved by the design team before they are merged into this project
• Components should have a prose description and live demo of different component states (using real data)
• UI components are accompanied by documentation to show how the component should be used within a real app. The UI components should rely on a parent component to contain state, however in some cases local state may be used to handle UI-specific concerns (such the location of a popup or visibility)
• Semantic versioning / version history updates when making releases
• Zero side-effects, including any exported CSS files from any third-party libraries.