After much discussion about common concerns of HOCs and reading #97 with it's proposed solution #182 I believe it's now time for this proposal.
At material-ui we had the same issue and after a lot of discussion with the team and specially @nathanmarks we came up with the solution and I implemented it.
The idea is, we should have a single HOC that hosts multiple features.
Although it's still in development I have used it in production and it works very well. The API is very simple:
import feature1 from 'react-mixout-feature1';
import feature2 from 'react-mixout-feature2';
import feature3 from 'react-mixout-feature3';
import feature4 from 'react-mixout-feature4';
// Component ...
export default mixout(feature1, feature2, feature3, feature4)(Component);
Since the API for making features is very strict yet enabling, it's very hard for logics to get mixed up.
If your features are implemented using react-mixout #97 is resolved effortlessly.
Also, the solution proposed in #182 doesn't work when the modifications aren't only related to props, such as context, validation, imperative methods, etc. These are all covered by react-mixout :grin:
That's a cool library! One of Recompose's goals, however, is to not introduce new abstractions and just stick with higher-order components. I prefer the approach in #182 because it will allow the user to use HOCs the normal way, without having to think about component-squashing because Recompose handles it automatically.
What's nice is that these two libraries don't necessarily compete, since HOCs created by mixout and the HOCs created by Recompose (or any other HOC library) are compatible.
What's nice is that these two libraries don't necessarily compete
Absolutely, no argue that this library has a lot to offer that mixout can't dream of. This was merely a proposal for consideration, I saw people struggling with the limitations of HOCs and thought I should let the maintainers of this library know about mixout. Feel free to take a look a the code and get some ideas. I have solved some common issues of HOCs as well, like ReactTransitionGroup compatibility, imperative methods (focus, blur, select, etc.). I use this library alongside mine in production and they work really well together :grin:
Most helpful comment
Absolutely, no argue that this library has a lot to offer that mixout can't dream of. This was merely a proposal for consideration, I saw people struggling with the limitations of HOCs and thought I should let the maintainers of this library know about mixout. Feel free to take a look a the code and get some ideas. I have solved some common issues of HOCs as well, like ReactTransitionGroup compatibility, imperative methods (focus, blur, select, etc.). I use this library alongside mine in production and they work really well together :grin: