Design Pattern and Refactoring
With the ever growing lines of codes that we write into our project everyday, we tend to get messy and do not even know how to add features anymore. Yes, it might be a running code, but it will not be soon if we do not do something about it. Having techniques such as refactoring will sure guide you in making the best structured codes.
“I’m not a great programmer; I’m just a good programmer with great habits.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code
React JavaScript: HOC (Higher Order Component) Design Pattern
React JS revolves around states and props, and these properties can be messy when you are working under variety of functions. With the use of HOC pattern, we can implement a “habit” so that simple components can reuse the same codes.
To put it in words, HOC is a JavaScript function that takes a component, inject or add additional data and functionality and return the new component with those additional data.
To go deeper, lets look at the codes below:
const newComponent = (BaseComponent) => {
class HOC extends React.Component {
render() {
return <BaseComponent />;
}
}
return HOC;
};const updatedComponent = newComponent(oldComponent);
We can see that updatedComponent
is a baseComponent
that is enhanced by a function called newComponent
. ThenewComponent
will give additional functionality or data from baseComponent
adding them before/during the render()
function.
How Moodah POS use HOC
During our project development of Moodah POS, we are asked to use HOC pattern for Front-end. It is reasonable to use HOC design pattern because the project will have pages with similar characteristics(e.g: list display, forms, etc).
Both tables uses different
With the use of HOC, each models can have have a same base component, yet have a different “added value”. In our case, we use added filters, offset, and limit for our posConfigs table. In the code above, both posConfigs and ResPartner will give the same additional property; filters,offset,limit. However, we can choose to delete any of those variables if not needed(because there can and will be table that does not need limit/offset/filters feature) for a table in the future! pretty neat huh.
Now that we know the importance of design pattern, hopefully we can do better in structuring our codes! yay~