Why use hoist-non-react-statics?

[quicksnap]

I'm asking this from a discussion in formatjs/formatjs#196 that got me curious on this decision.

The gist of the discussion in from the injectIntl HOC via @ericf:

I don't consider it a bug, but a design choice. Forwarding statics can be brittle and isn't required for React's component rendering protocol. I did research this and found that many of the usages where people want statics forwarding were for Flux related metadata and functions are not part of the component's own encapsulation; i.e. the component itself never accesses these statics, nor does React the framework. It seems that statics is used as a convenience in a component created with React.createClass() that's defined as a CommonJS module so that people don't have to type FooComponent. multiple times when defining their statics.

This makes sense to me. While I have used connect's hoisted statics for server rendering, I wonder if it's encouraging a bad pattern. Since the result of connect is indeed another function, and static methods aren't normally maintained in higher order functions, should developers using connect be aware of this and instead define statics on the result of connect instead?

I personally am not looking for change by removing hoist-non-react-statics--simply interested in reasoning about the decision to use it.

[gaearon]

Practical choice.

#270 (comment)

Static methods are hoisted because that's where people tend to put data fetching methods. There's no workaround here, and call sites are often generic doing something like "grab every fetchData static on components matched by router". So it's worth it there.

We didn't do that before and people had too many issues putting stuff like fetchData() on their components. Hoisting just statics seems like a worthy tradeoff.

[quicksnap]

facepalm I should have searched. Thanks for the quick reply!