react-ui

React-UI is implemented as a monorepo managed with Lerna to facilitate scripts, versioning and publishing.

For simplicity, yarn run clean and yarn run build will execute lerna run clean and lerna run build, respectively, which will traverse packages and run the intended scripts in all of the individual packages.

More Lerna commands. Please use yarn publish-packages to semantically publish and generate a CHANGELOG for all repos below.

Package	Version	Description
`react-ui-core`		Core components for generic usage
`react-ui-tracking`		Tracking HOCs and components
`react-ui-utils`		Utililty functions used to make things easier in all repos

Commitizen

This project uses commitizen. This allows us to automate CHANGLELOGs and version bumps in each repository. It will include your commit in the changelog by using git cz when you commit

Anything that is included in the BREAKING_CHANGES section of the prompt will automatically bump the package version for the repo to a major version.

Also, please keep in mind your scope should be what you were working on. It should be something like form or listing or photo. The short description of change should be precise as it's what you will see in the CHANGELOG (along with the scope).

Working Locally

Follow these steps to work with your local files instead of the published versions:

cd into the react-ui package root folder, e.g. packages/react-ui-core
run yarn
run yarn link (in packages/react-ui-core)
cd back up to the react-ui root folder
run yarn build:cjs:watch (or yarn build:es:watch if you are using es modules in your client project). This will compile all files, including dependencies in react-ui-utils, then only change what's needed thereafter.
in your client project's root folder, run yarn link @rentpath/react-ui-core

react-themed

Many react components use react-themed when needed. Please read the documenation if you're not familiar with it.

CEM (BEM) syntax and clsx

For information on BEM, please read

All components should follow a CEM (Component Element Modifier) syntax. The top level element in your component should usually have the component name as the className. Every child should use the Component className as a prefix unless you are importing another component that has already been themed. A good rule of thumb to use:

import clsx from 'clsx'
import Button from './Button'

class SomeComponent extends PureComponent {
  render() {
    const { theme, className } = this.props

    return (
      <div
        className={clsx(
          theme.SomeComponent,
          className,
        )}
      >
        <span>My Component</span>
        <Button>GenericButton</Button>
        <Button className={theme[Button-red']}>Some red button</Button>
      </div>
    )
  }
}

Notice the above. The top level component uses clsx to include the base class (SomeComponent) and the ability to pass in a custom className prop. The first <Button> does not get a className because it is already themed. The second <Button className={theme[Button-red']}> component takes in a className with a modifier that gets appended to button the same way the top level component uses clsx.

Naming conventions

.Component_Element-modifier

Element is always prefixed with _ and PascalCased Modifier is always prefixed with - and camelCased

Examples

className	C	E	M
.SomeComponent	X
.SomeComponent_Navigation	X	X
.SomeComponent_NavigationControls	X	X
.SomeComponent-red	X		X
.SomeComponent-isActive	X		X
.SomeComponent_Navigation-next	X	X	X
.SomeComponent_NavigationControls-invalidError	X	X	X

ModalStack

Documentation on using ModalStack can be found here.