Standard mixin substitute for ES6 classes

[marnusw]

The well used react-onclickoutside mixin for detecting mouse clicks outside a React Component cannot be used with ES6 classes. I have proposed a wrapper function/higher-order component/decorator in a PR at Pomax/react-onclickoutside#22.

The author @Pomax has asked me to check in and find out whether this aligns with what might become the official approach to realizing mixin-like functionality for ES6 classes before he merges it?

It seems to be becoming a de facto standard with a couple of larger libraries following this approach including Yahoo's Fluxible in connectToStores() and Material UI in ThemeDecorator(). The Relay syntax also appears to be similar?

The intended use is documented with the changes in the PR mentioned above.

[Josh-a-e]

I too would be interested to know if this is going to be the recommended way to abstract common behaviour.

I've arrived at the point now where I'm writing my own decorators but feel somewhat apprehensive to do so with their future being a little unknown. That said they seem to be increasingly popular (especially in the absence of mixins) and my personal vote would be to support them, mainly as there don't appear to be many viable alternatives, other than perhaps something based on multiple/chained inheritance which seems much less common.

I'd also add react-redux's @connect() to the list of popular implementations and there are a number of interesting discussions on the topic, specifically reduxjs/react-redux#1

[Josh-a-e]

For reference https://github.com/wycats/javascript-decorators

[gaearon]

Please don't confuse decorators (syntax) with higher order components (pattern). Even if decorators are not going to end up in ES, nobody will take Component => Component functions from you, which is all higher order components are.

[jimfb]

The mixin system was/is flawed in more than one way. In most cases, higher order components do solve the common use cases for mixins. I would recommend reading https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750

It sounds like you have a solution that utilizes higher order components, so (without having actually looked at it) that's likely the solution we would recommend. If you have a problem which is normally well-solved by mixins but is not well-solved by HOCs and/or sideways data loading (#3398, #3858) then we would LOVE to hear your use case, please open a new issue that describes the use case.