Recompose: breaking change in lifecycle. this not automatically bound to custom functions

[bonjowi]

Updated recompose from 2.0.2 to 2.4.0 to get rid of React.createClass deprecation warning.

Discovered breaking change in lifecycle

Code which used to work:

function componentDidMount() {
    this.anotherFunction()
}

function anotherFunction() {
    this.props.dispatch()
}

lifecycle({
    componentDidMount,
    anotherFunction
})(Component)

Now gives error:

Uncaught TypeError: Cannot read property 'dispatch' of undefined at anotherFunction

Now I am required to bind this
this.anotherFunction().bind(this)

[istarkov]

https://github.com/acdlite/recompose/pull/391#issuecomment-306867983
@Andarist can you help?

[Andarist]

@istarkov sure, ill look into this asap

[Andarist]

@bonjowi could u tweak this example - https://codesandbox.io/s/76QRB9pmB to reproduce ur issue (dont forget to Save)? information given by u is not sufficient yet to isolate the problem

[bonjowi]

@Andarist I've just found out it's only happening when i use an eventlistener as such:

window.addEventListener('resize', this.anotherFunction);

I have updated the example too: https://codesandbox.io/s/rkEzG2JvK

[istarkov]

In addEventListener case updateDimension is not bound to this.
I don't think that we will change the behaviour we have now, it was autobinding in React createClass but it's not exists in newer ES6 classes.
So please bind by yourself or use

window.addEventListener('resize', () =>this.updateDimension());

[bonjowi]

@istarkov sure, if that's the case I'm happy to update my code. Thanks guys for your fast response

[istarkov]

@Andarist thank you for your help and codesandbox code, I'll use it for playing with other issues and other code.
I haven't use it before, seems like more easy to play with vs jsfiddle

[bonjowi]

I would like to add on my issue that I was under the impression recompose used semver. According to semver, such a breaking change should be a major version update.
What do you think?

[Andarist]

npm rules for semver before v1.0.0 are different.

You can read more here. Especially this fragment:

Many authors treat a 0.x version as if the x were the major "breaking-change" indicator.

Caret ranges are ideal when an author may make breaking changes between 0.2.4 and 0.3.0 releases, which is a common practice. However, it presumes that there will not be breaking changes between 0.2.4 and 0.2.5. It allows for changes that are presumed to be additive (but non-breaking), according to commonly observed practices.

[bonjowi]

Thanks for explaining. In that case, as far as I'm concerned, the issue can be closed.