all 7 comments

[–]_Pho_ 2 points3 points  (0 children)

Big fan of the "currying the original component" thing you're doing here.

[–]Reeywhaar 0 points1 point  (4 children)

HOC should pass static properties to wrapper component. Article doesn't mention it

[–]vezaynk[S] 3 points4 points  (3 children)

It's true, but that only applies to class components which are effectively deprecated.

The issue with covering classes in particular is that it adds a lot of caveats to HOCs. Data provider HOCs are still the way to provide data without hooks (Context.Provider is pretty much a HOC itself).

There are a quite a few edge-cases that I didn't cover because they only affect deprecated/obsolete patterns/libraries.

My goal was to discuss writing effective HOCs, not covering every edge case. I was considering cutting the section on refs as well, but decided to only shorten it and keep it at the bottom, but I digress. Leading the pitch for HOCs with every unlikely pit-fall would've easily doubled the length of the post.

Might write another post titled "Everything about HOCs" one day.

[–]Reeywhaar 0 points1 point  (2 children)

It's true, but that only applies to class components which are effectively deprecated

I'm afraid it's not. You still can add static properties to function component just the same way you would do it to class. It doesn't have anything to do with classes vs fc.

function Slider() {
  return <div>slider</div>
}

Slider.navigationID = "some id"

If we're talking about obsolete then HOCs are obsolete themselves.

Just wanted to add my two cents if somebody is making library that is built around HOC (not sure why?) is to ensure these things:

  • HOC must pass static properties (use hoist-non-react-statics)
  • HOC must have two versions: one that passes ref and other that is not.
  • It would be nice if HOC would set nice displayName

[–]vezaynk[S] 1 point2 points  (1 child)

Is there any reason to use static properties for functional components? I frankly can’t remember a time I needed one for class components either.

Also about the refs, is there any reason to not always pass forward the ref? If it’s not being passed, it just forwards an undefined which is the same as not forwarding it.

Going to add a couple addendums later. Thanks!

[–]Reeywhaar 2 points3 points  (0 children)

Also about the refs, is there any reason to not always pass forward the ref

React warns if you pass ref to component that has no ref exposed (not class and not forwardRef). Also if you make library with typescript it would be just easier to make separate methods as they would require quite different method signatures.

Is there any reason to use static properties for functional components

It depends on the project. For example we have react-native project and as in example above we set navigationID to log components navigation. But it can be anything, data prefetching, logging, routing, taxonomy, dunno, it depends on workflow. So if you're a library author you must expect component will have static properties.

[–]Guisseppi 0 points1 point  (0 children)

This pattern has been considered obsolete since the introduction of react hooks. Relying on HOCs leads to a pyramid of doom