At Rize, UI components are developed in this library and then imported into our main application where they are wired up to their container components. By separating the presentational components into their own library, we are able to enforce a strict separation of concerns and deeply enforce a single responsibility rule of how components that render UI should only be concerned with their appearance and interactivity (and not be concerned with application/implementation details).
How We Use This
This library is symlinked locally with the main application. Rize Blocks builds to ES6 modules, so the bundling process is taken care of in a downstream build process. The ES6 module build also permits tree-shaking in the cases that there are unused (experimental/deprecated) components.
Seems like overkill? This workflow works well for us for a two major reasons:
- Designing presentational components and their props happens in isolation, therefore props and components design tends to be less coupled to our app's state
- These components are developed entirely in storybooks, which provides an incredible developer's experience and imparts very high cohesion (the component visually align) and loose coupling (the components can exist independently to the largest extent possible)
Developing Presentational Components
Components are developed in individual stories.
Salt and Pepper
In cases where components have contextual dependencies on other presentational components, they can be developed in a story that has a combination of several components (e.g. seeing how a
<Button /> component integrates with the bottom of a
<Panel /> component in a
The only intances with considerable cohesion between the blocks and the main application is with forms. The link is in
redux-form is configured. This permits us to develop controlled components in stories.