reverse props spread order for mapPropsOnChange

[hartzis]

While working with mapPropsOnChange recently we noticed that this.props get spread over computed props.

https://github.com/acdlite/recompose/blob/master/src/packages/recompose/mapPropsOnChange.js#L24

It appears the original plan was to spread computed props last?
#60 (comment)

Example:
I create an items prop with mapPropsOnChange

mapPropsOnChange(['thing'], ({thing}) => ({items: thing.count()}))

but if items was already a prop being passed down the new computed prop of items will get overwritten by this.props.items.

I would expect my outputted computed props to be what gets passed down.

Let me know what you think, and I could get a PR in with tests this week.

[acdlite]

Yes this was an oversight. It can be fixed by flipping lines 25 and 26. A PR would be great :)

[istarkov]

For simplicity with line switch, omit on line 26 also can be removed. Otherwise it works like mapAndFilterPropsOnChange

[hartzis]

@istarkov it appears mapAndFilterPropsOnChange is not a HOC in this library. I do like the idea of that though.

[istarkov]

I meant that omit filtering was done because of merge order, if you switch lines 25 and 26, looks like there is no need to filter (omit) props taken from array.

[hartzis]

I have the PR pretty much ready to go, but trying to run the tests local and they are currently failing with:
Module build failed: Error: The (relay-query) Babel 5 plugin is being run with Babel 6.

I think it is related to facebook/relay#889, and when they publish a new version it may be fixed.

I may just submit the PR and see if the travis build fails.