Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standard mixin substitute for ES6 classes #5010

Closed
marnusw opened this issue Sep 30, 2015 · 4 comments
Closed

Standard mixin substitute for ES6 classes #5010

marnusw opened this issue Sep 30, 2015 · 4 comments

Comments

@marnusw
Copy link

marnusw commented Sep 30, 2015

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
Copy link
Contributor

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
Copy link
Contributor

@gaearon
Copy link
Collaborator

gaearon commented Oct 12, 2015

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
Copy link
Contributor

jimfb commented Oct 16, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants