Some developers I work with dislike that recompose creates HOCs on each operation, so the tree in react tools is too deep.
As an example:
This code
https://github.com/istarkov/google-map-clustering-example/blob/master/src/GMap.js#L57-L126
creates this tree

The real examples we have at work has more deeper trees. (I does not use react tools at work, but others use it a lot)
And Yes I know that I can combine here 3 call to withState into one or/and mapProps.. but this affects code readability for me.
I think that some of that multiple calls can easily (or not ;-)) be combined at compose level, as some optimization operation.
For example sequential calls to mapPropsOnChange can be combined into one HOC automatically and etc....
May be it's too early to talk about this, but it's just an opinion of some developers.
We address this in part using our custom version of createElement(), which avoids unnecessary intermediate React elements by detecting referentially transparent function components. This only works with certain helpers like mapProps() — helpers that use lifecycle methods, context, etc necessarily require a class component.
So there's only so much we can do here. Better documentation and examples that illustrate best practices is needed.
For example, instead of using two sequential mapPropsOnChange(), use a single mapPropsOnChange() and compose the mapping functions together.
Instead of multiple withState(), use a single withState() or use withReducer().
Or if your component is sufficiently complex and the extra elements concern you, then perhaps Recompose isn't the right fit for that particular component and you should use a regular class instead.
See https://github.com/acdlite/recompose/issues/182 for a potential solution to this problem
Most helpful comment
See https://github.com/acdlite/recompose/issues/182 for a potential solution to this problem