RFC

As a developer I want to clearly separate the visual components from the glue components as we bring in V1 features into V2 so that we can easily story book those components that do not access global state or send API calls and keep our code lean and easy to develop.

glue component: term for components that access global state or send API calls and are thus not easy to unit test or storybook. They are also known as “connected,” “smart,” or “impure,” but I like “glue” to encourage us to only use them as a glue layer between logic and view, and keep them as lean as possible. Glue components send messages, render org data and error messages.

visual component: components that don’t use global state or send API calls. not “pure” components because they can hold component state, such as a toggle button that you can click on or off or an input that can hold unsubmitted text. What they render depends only on their props and that kind of local user interaction, resulting in components that take maximize what we can easily unit test and put in Storybook. (It may also use the theme, which is delivered via Context Provider, and which unit tests and Storybook can handle.)

Further:
For separation of concerns, use the global state machines to encapsulate API calls. For instance, the Organizations machine knows how to add, delete, update, and read organizations from the backend, and the glue components do not (they merely send messages like "GET_ORGANIZATION" and render either organization data or error messages.

This will mean:

• DRYer component code - instead of two page components writing the same promise handling code, the global state machine writes it once
• leaner and easier to read glue components - I expect sending messages to the global state machine and receiving its state to amount to less code and fewer conditions in the components than handling the API calls there
• the ability to change the API contract with minimal impact on the frontend codebase - just edit the global state machine