HOC - The Gift That Keeps On Giving
As the new year is rung in I look back on what has gotten me through 36 years of life as well as 2020… which may as well of been 36 years rolled into one. The biggest reason I am where I am in this bootcamp and in this life is due to my family and friends. While I am James Ardery the individual I am also a member of the Ardery family. While I am Jame Ardery the student I am also a member of the Flatiron 100520 cohort. While I am capable of handling many situations on my own other situations I very need my family and friends to help get me through. Be it a code concept I am struggling with or just a hurdle in life that has brought me down. The Ardery family name or the 100520 cohort badge are the Higher Order Components in my life and so the life code parallels continue.
There is a need to share common functionality amongst components without repeating code and that is the reason why Higher Order Components, HOCs for short, exist. As programmers we are constantly trying to DRY out our code. While an HOC can be used in many different applications across React the definition is quite straight forward. A HOC is a pattern where a function takes in a component as an argument and returns a new component.
Standard conventions and practices used with HOC include the original component typically being referred to as wrapped component. The 100520 badge wraps James the student and produces James the Software Engineer. The Ardery name wraps James the individual and produces (fingers crossed) James the adult🤞.
HOCs are typically used to abstract logic to a single place and then pass that logic in across many components that it wraps. The wrapped component then gains additional data, functionality, methods, or logic passed from the HOC. Technically the wrapped component is not modified by the HOC but is instead composed by the HOC. I am still James but I am modified and enhanced by the 100520 badge and Ardery name.
Another analogy for thinking about HOC is the comparison to Ironman the Marvel character. Technically the character Tony Stark is still the same Tony Stark even after he has been wrapped in the Ironman armor.
Technically you can use a HOC to mutate the wrapped component but it is advised against or even considered a leaky abstraction (bad parenting/friendshipping?🧐).
When the HOC mutates the wrapped component you loose the ability to reuse the wrapped component separately from the HOC. If friends and family mutate me I am bound to them as my identity is a result of their actions. Also another more detrimental byproduct would be if you apply a HOC to the first HOC (withArmor in the example above) then the original HOC functionality will be overridden!
A few examples of HOCs that I have come across in the MOD-4 of Flatiron bootcamp is the connect and provider functions in Redux. Connect is a higher order component that allows us to pass props including dispatch, action, and state as well as others via MapDispatchToProps (PUB) and MapStateToProps(SUB) function. Provider passes the Redux store to our App.
Another use of HOCs that is common to React is BrowserRouter in the react-router-dom library. BrowserRouter passes router props into an application which include history, location, and match. The restful dynamic tag :id is used after a given route in order to render a show page for a given component localhost3000/cities/:id. Id is then accessible via the router props passed in from BrowserRouter and can be access in our match.params.id.
Another very common routerProp used is the history prop which we use in our forms. When creating a new object( city) our form passes the new state object created back to our fetch request which then uses that object to push on to our database.
Our .then returns the new city, but from a user standpoint our route is still associated with the /createForm page. The history prop passed down via the BrowserRouter HOC gives us access to a variety of functions one of which is .push which allows us as devs to push the user to the `/cities/${newCity.id}` that they just created. Conversely the history prop also allows us to push a user back to the previous page they were on. None of this would be possible with the HOC props passed down to our app component from BrowserRouter
Friends and family provide me the tools to complete a task similar to how connect provides MapDispatchToProps allowing components to update their state. Friends and family provide guidance similar to how BrowserRouter can .push an object to its new home or can remind a user of the previous pages they have visited via .history props. The user is still the same. The object being created is unchanged, but with the help of HOCs life becomes that much easier and more empowering. Thanks for all the help HOCs, Family, and Friends :).
References:
