Solving the problems of Higher Order Components without throwing the baby out with the bathwater

There have been some criticisms laid against Higher Order Components in recent articles — specifically “indirection” and “naming collisions”, that aren’t actually problems inherent with the HoC pattern, but are rather usage errors that can be easily avoided. Explicitly defining prop names Here is recompose’s HoC withState There’s no confusion about where the props and come from, and since you’re in control of what to name the props, collisions are also not a problem. counter setCounter Let’s apply the same principle to the example taken from Michael Jackson’s ! withMouse Use a Render Prop Since you are declaring what to name the prop you are about to receive right where it’s being used, there’s no issue of indirection or collisions. What if your HoC needs to return multiple props? Imagine that the HoC returned two props - , which contains the and coordinates, and , which keeps track of the number of times the position has changed. withMouse position x y changeCounter Requiring each prop to be explicitly named would make the HoC more cumbersome to use with each additional prop that it provides. But without explicitly naming the props, you might end up with something like this: You could only guess that the and props came from and not the other HoCs, and you’ll have to assume that none of the other HoCs return props with the same names. position changeCounter withMouse Namespacing Higher Order Components That ambiguity/indirection and conflict potential can be solved by namespacing the HoC: You could go even further and namespace all the HoCs (this works with any HoC that returns props) Props are now traceable via namespace back to the HoC that provided them, and since namespaces are set when an HoC is being composed, collisions can be avoided as well. The code for the function is actually really simple namespace with it all together Here’s a sandbox Something Render Prop does better Render Props does have the benefit in that you can sprinkle it into a render function. M_y_ friend has a great example demonstrating the utility of this that I hope will be turned into blog-form soon, but in the mean time here’s a simpler and more contrived example — Alex Wilmer Let’s say you’re inside a large-ish block of JSX and there are some hardcoded and repeated variables (in this case, “Eastasia”) that you would like to DRY up. You have a few options. Declare the variable up at the top of the function (which adherents to “declare variables close to where they are used” may not like) Create a separate component and pass the repeated values in (which is somewhat of a hassle) Create a component called that we can assign values to via props, then receive those values back in the render function. Let’s go a little further and say that the values would come from async requests. You could make a component that does this… I’m not actually sure if using these components is a good idea (consult your nearest thought leader 😄), but it demonstrates where Render Props would allow a certain flexibility that, to my knowledge, HoC would not. Summary We seem to go through stages of “Huh, I didn’t realize you could do that” “This seems to be a great solution” (for certain use-cases) “This is the objectively superior solution!” “There are tradeoffs and pitfalls. Here is where this solution makes more sense, here is what you need to be careful about, and here is when it’s better to use something else.” I think we’re at Stage 4 with Higher Order Components, there are . With Render Props, the articles I’ve seen so far seem to be still between Stage 2 and 3. traps that you could fall into, but also solutions to them as well Everything is a tradeoff. I’m suspicious of a solution that’s presented as all benefit and no cost — that usually just means the costs haven’t been discovered yet 😄 Feel free to fill me in in the comments on what I’m missing, , or tweet at me discuss on reddit @CheapSteak This article is sponsored by Compare npm package download counts over time to spot trends and see which to use and which to avoid! npmcharts.com 📈 Here’s an interactive download chart for recompose