Background
I noticed that in my application, there are a few logic that are used across multiple components and writing them into each individual components will make maintenance harder and prone to error. Logics could be UI-related to systems related. Incorporating business logic into the frontend may raise eyebrows and trigger debate on the design decisions. Here, we explore the safer topics.
What Higher-Order Component (HOC)
In general, HOC is a function that takes a component and returns a new component. The reason for doing this is to reuse logic that could also be used in another react component. We layer the logic away from the component so as for maintainability as there is also the possibility of migration if your base component is from library.
For more detailed explanation, you can read it at the official React page here.
Examples
#1 Basic: Pure component wrapping — no sharing of logic or data
Information buttons are common component within sites to give an explanation on what the component does. This is usually used with tooltip function for easy display of information. The tooltip functionality would likely be implemented using a library that provides customization on the animation and style of the tooltip.
The code for the I-button could be implemented in several ways including having components taking in Info button component which allows flexibility of Info button placement but have an dependency on the I-button.
Another design if UI allows for it would be for each component to be wrapped with I-button on the outside through HOC.
Similar use cases: Accordion, Theme.
#2 Data: Category/sub-category data
The second example is the main category and sub-category component. Selection of the main category will result in a different list of values for the sub-category. The city-selection component will be passed with data based on country-selection component.
The sample code below wraps the component with a main component drop-down list selector and will provide it with an array of cities for display.
For this particular example, it might seem like over-engineering to separate the category/sub-category logic. It would be much easier just to generate a category/sub-category component and the logic would most likely not need to be extended to other components. I think both ways work and by working out through the HOC, we are able to separate UI logic from the component itself and there would definitely be stronger justifications if the application have multiple category/sub-category logic and this could generically handle all of them or if there is need to extend the logic to other components.
Similar use cases: Internationalization and localization
#3 Logic: Content loading logic
The article from the official React page (here) described the scenario of content loading into components. Let us explore this use case here.
The logic should somewhat be like this — on page load, show a loading screen and trigger a fetch to the backend for data. Once the data is back and ready, the component would re-render showing the display with data.
#4 Logic: CQL (Common Query Language) filtering of map layers logic
Common Query Language (CQL) is a query language created by the OGC for the Catalogue Web Services specification. It is a text-based syntax used for filtering. However, not all users are proficient in CQL. Hence, instead of getting the users to directly write CQL language, we provide filtering functionality through GUI (e.g. toggle buttons, dropdown list, etc…).
Similar use cases: Layer Definition, GraphQL.
Conclusion
Separating logic out allows better maintainability and faster scaling out to other components requiring the same features. However, communications within the team about the design is important. They might miss the HOC and implement a solution of their own.
Do you have any interesting examples to share? Comment below to let me know.
