[skwosh]

It's not clear to me why (in the pattern presented) the decorators don't return a subclass (which would preserve the dynamic and static properties and methods, etc). Instead you get hacks like `hoist-non-react-statics` to copy them over manually.

For context, the article advocates the following:

    import GlobalClass from 'global-class'

    const decorator = SuperClass =>
        class extends GlobalClass {

            render() {
                return <SuperClass {...etc}></SuperClass>
            }

        }

This can be rewritten to remove the fixed dependency on `GlobalClass`, while preserving the underlying type:

    const decorator = SuperClass =>
        class extends SuperClass {

            render() {
                // const SuperClass = super.constructor // if you want to be less explicit...
                return <SuperClass {...etc}></SuperClass>
            }

        }

The only requirement is to maintain the contract outlined by the `SuperClass`, but that's what `super` is for. (By that I mean e.g. that `componentDidMount` should't be overwritten without also calling super.componentDidMount() before/after).

Returning a different kind class entirely limits the utility of the pattern in general (IMO), and you lose the nice function-composition-like behaviour provided by `super.method`.

[danabramov]

In our experience inheritance causes a lot of hard-to-find issues, and muddles boundaries between component concerns. Some of the same problems I described we had in mixins also apply to inheritance.

>and you lose the nice function-composition-like behaviour provided by `super.method`.

We found this to be an anti-pattern. It’s easy to get lost in virtual calls across hierarchy, and people are going to create virtual methods (and override them) if you allow it.

>Instead you get hacks like `hoist-non-react-statics` to copy them over manually.

An alternative is to just not put static methods on component. It’s not such a useful feature.