Recompose: Consider adapting react-mixout

Created on 24 May 2016  路  2Comments  路  Source: acdlite/recompose

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.

react-mixout

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:

Most helpful comment

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:

All 2 comments

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:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

SeanGroff picture SeanGroff  路  4Comments

rndmerle picture rndmerle  路  3Comments

robbporto picture robbporto  路  3Comments

astanciu picture astanciu  路  3Comments

isubasti picture isubasti  路  3Comments