Page Comparison

...

• Currently the webapp package of our repository has two directories containing React components, components and containers. Components is meant to contain “pure” "pure" components which hold no business logic and don’t don't connect to the Redux store, whereas containers holds more complex components handling application logic. However, there are several cases of files in the components folder containing smarter, more complex components, which indicates the distinction between the two can be confusing.

• Because the components in the components folder are meant to not hold any logic, they should be more reusable and resemble more closely an implementation of a design system. However, a lot of these components are not generic and are built out for specific screens and purposes, e.g. CertificationSurvey, ChooseFarm or CropListPage, which means they aren’t applicable to new features and are not part of the design system.

• All of the above makes it hard for developers to identify which components can be reused when building a new feature – this fosters the creation of more domain-specific components with each new feature built, which in turn aggravates the problem and slows down development.

• Another ill consequence of having domain-specific components is the challenge to creating a cohesive user experience. When a UX or visual pattern is updated on the design side, several domain-specific components will need to be updated. An example of this is the PureTaskDropdownFilter component. This components implements quick filters, sorting and a filter button for more advanced filters – all features that could be useful for other pages in the application. However, since it’s built out specifically for tasks, if we wanted to introduce this same UX pattern to, for example, the Crops page, we’d need to either create another domain-specific component just for crops or either spend some time abstracting the component to make it reusable. Either way, shifting the mindset and creating reusable components to be generic from the start would save significant development time.

...

• We need to selectively migrate components that are actually reusable and can be considered “core”, and remove stories for those that aren’t, until we get to a point where the previous Storybook can be removed altogether.

• We need to make sure that for the components we do migrate, their specification still matches the updated design system. If there isn’t an up to date design spec for the component, we should work with Design to get that in Figma.

To achieve this, I suggest doing a review of existing components and drafting a proposal for which ones should be included in the new library, guided by the design system that’s being implemented in Figma. Once we have that, we can create tickets to migrate the core components over time.

...