Higher-Order Components are actually a design pattern derived from the compositional nature of React, which allows us to derive components based on particular data we want to pass down to them. Think of it this way: Components return React Elements (JSX) Higher-Order Components return Components Don’t get confused — a HOC itself is not a component. Remember: Components are functions that return a React element (JSX Element), higher-order components are the functions that return those components. At a higher level of abstraction, an HOC would look something like this: const withHOC = (Component, someData, otherArgs) => { return (props) => { return ( <Component customProp={someData.firstProp} dataSomething={otherArgs.someOtherDataProp} {...props} > <h2>Might as well add nested elements</h2> </Component> ); }; }; symbolizes the defacto (the most commonly used) naming convention when working with HOCs with … And a example of how this would be used: non-practical import withHoc from 'previous-gist'; const Component = (props) => { return ( <div> <h2>Hello!</h2> </div> ); }; export default withHOC( Component, { // `someData` argument prop1: 'what's good?', prop2: { propProperty: 'holding some data' }, }, { // `otherArgs` argument arg1: { property: 'some-value' } }, )(); Now that we’ve gotten a bit more familiar with this concept, let’s go into a more realistic scenario where you might find yourself in need of HOCs. Project Setup Folder Structure: You can check out the repo here: for the entire project file system structure. https://github.com/Vlad-Mihet/React-HoCs Brief overview: : will contain the stored blog posts, with an afferent getter method for retrieval src/api : will contain generic components; in our case, it will be : which will act as a presentational component, and only display the blog posts passed down to it src/components BlogsContainer : will contain the views of the application; in our case, it will only be the view, which will render a list of Recent, Popular & Archived blog posts through the container components in src/views Home src/views/home/components : will contain view related components; in our case, these will be all container components: , , and , which will all be responsible for fetching their own data src/views/home/components Home ArchivedBlogs PopularBlogs RecentBlogs : will embed the view src/App.js Home So, what is the issue with the setup? Well, we do have different components for a rather similar task: Initializing a piece of state for blogs, receiving the same prop, updating the blogs state at mount time, and rendering it with the same component. blogs BlogsContainer It is code duplication that could be solved through the implementation of a Higher Order Component. Solution Create an HOC under with the following content: withBlogs src/hocs import { useEffect, useState } from "react"; const withBlogs = (Component, retrieveBlogs) => (props) => { const [blogs, setBlogs] = useState([]); useEffect(() => { setBlogs(retrieveBlogs); }, []); return ( <Component blogs={blogs} {...props} /> ); }; export default withBlogs; The HOC would get a Component, as well as a blogs retrieval method as parameters, and will be tasked with fetching the blogs data and returning a component with the prop set as the retrieved blogs data. withBlogs blogs Next, in the view, we could discard the components we have used from , and define the new components created by our new HoC: Home src/views/home/components import React from 'react' import { getArchivedBlogs, getPopularBlogs, getRecentBlogs } from '../api'; import BlogsContainer from '../components/BlogsContainer'; import withBlogs from '../hocs/withBlogs'; const RecentBlogs = withBlogs(BlogsContainer, getRecentBlogs); const PopularBlogs = withBlogs(BlogsContainer, getPopularBlogs); const ArchivedBlogs = withBlogs(BlogsContainer, getArchivedBlogs); const Home = () => { return ( <div className='home'> <section> <h2>Recent Blogs</h2> <RecentBlogs /> </section> <section> <h2>Popular Blogs</h2> <PopularBlogs /> </section> <section> <h2>Archived Blogs</h2> <ArchivedBlogs /> </section> </div> ); }; export default Home; Not only have we reduced code duplication, but we have also implemented a simpler and more easily-readable solution. Now, you might be wondering, why don’t we simply use the component inside the HOC, rather than using a generic parameterized component? BlogsContainer withBlogs Well, what if we ever want to maintain the same functionality, but in another case? For example, we might have a banner component that fetches blogs, but displays them one by one in a vertical scrolling fashion? In that case, we won’t be passing props to style the BlogsContainer component, but rather have another Banner component. Should you still use HOCs? Well, it depends. Is the project you are working on using Class-based components? If yes, it’s pretty likely you would need to use HOCs, since hooks are not available for them. Otherwise, I do consider that hooks are still a better approach to the issue we have had an overview of. Let’s see how hooks would solve our issue: First, we would have to create an hooks to handle the retrieval of the blogs data: useBlogs import { useState, useEffect } from 'react'; const useBlogs = (getBlogs) => { const [blogs, setBlogs] = useState([]); useEffect(() => { setBlogs(getBlogs()); }, []); return [blogs, setBlogs]; }; export default useBlogs; And then we’ll have to update the components’ definitions in the view: Home import React from 'react' import { getArchivedBlogs, getPopularBlogs, getRecentBlogs } from '../api'; import BlogsContainer from '../components/BlogsContainer'; import useBlogs from '../hooks/useBlogs'; const RecentBlogs = (props) => { const [blogs] = useBlogs(getRecentBlogs); return <BlogsContainer blogs={blogs} {...props} /> }; const PopularBlogs = (props) => { const [blogs] = useBlogs(getPopularBlogs); return <BlogsContainer blogs={blogs} {...props} /> }; const ArchivedBlogs = (props) => { const [blogs] = useBlogs(getArchivedBlogs); return <BlogsContainer blogs={blogs} {...props} /> }; const Home = () => { return ( <div className='home'> <section> <h2>Recent Blogs</h2> <RecentBlogs /> </section> <section> <h2>Popular Blogs</h2> <PopularBlogs /> </section> <section> <h2>Archived Blogs</h2> <ArchivedBlogs /> </section> </div> ); }; export default Home; Through the hooks approach, we can benefit from handling the compositional aspect of React much more elegantly, not having to define a boilerplate HOC, but rather a nicer hook, and use that as needed, without having to go through multiple component factories just to get various props. It also allows us greater control over the state, which is a huge plus in case we need to do some more extensive computation on the blog state of each component, like filtering or sorting through the blogs. Final Word I do believe that HOCs are extremely useful to understand, but if you are not actively working with Class components, I strongly suggest you would look into hooks, as they are simpler to work with overall. I hope you have learned something new by reading this article, and hope you have enjoyed it. Catch you on the next one! Cheers! If you have enjoyed reading this article, you can also support me by buying me a coffee . here Also published here
