Using Lifecycle with ES6 classes

[taion]

It seems like a number of our users are complaining about finding it difficult to set up routerWillLeave hooks when using ES6 classes.

Personally, I think the right thing to do is to either suck it up and re-implement the code from the Lifecycle mixin, or drop back to React.createClass.

However, there's another option that's viable here that we'd be remiss not to consider. We could add something like a LifecycleWrapper class. The API would look something like:

render() {
  return (
    <LifecycleWrapper onLeave={this.onLeave}>
      {/* Whatever the component was going to render anyway */}
    </LifecycleWrapper>
  );
}

The benefit of doing it this way is that the onLeave hook will have access to e.g. state and props on the current component, in a very similar way to routerWillLeave on the Lifecycle mixin, while also freeing the user from explicitly managing the listener's lifecycle.

What do y'all think?

[timdorr]

What about a decorator/HoC style option?

@Lifecycle
class Thing extends Component {
  routerWillLeave(nextLocation) { 

Which can also take the form of:

export default Lifecycle(Thing)

[taion]

D'oh. Major brain fart. Forgot about that option.

Even simpler, though, what if we just point users at e.g. react-mixin or something for applying mixins to ES6 classes?

Otherwise we'd need a separate @Lifecycle for ES6 v. LifecycleMixin for React.createClass.

[taion]

Another option might be to rename Lifecycle -> LifecycleMixin (and correspondingly RouteContext -> RouteContextMixin), then declare Lifecycle as reactMixin.decorate(LifecycleMixin), which provides the option from #2364 (comment) without having to write any code.

That way we don't need our users to explicitly have to bring in react-mixin if they're using ES6 classes and want to use this functionality.

I think on balance I like what I have in #2372 more, though - these really are and probably should be mixins, for which using react-mixin pending any official language-level mixin support seems like a fine pattern.

[gaearon]

Even simpler, though, what if we just point users at e.g. react-mixin or something for applying mixins to ES6 classes?

To be honest react-mixin always felt like a big hack to me. I wouldn't suggest using it, either internally, or suggesting others to use it. HOC pattern is much clearer, and I'd rather have two different ways to apply something (HOC and mixin) than use react-mixin. But that's my personal opinion.

[taion]

@gaearon

To me the issue is that if we were natively exposing this, the implementation would be identical to just doing export default const Lifecycle = reactMixin.decorate(LifecycleMixin). From an API cleanliness perspective, we'd want to modify the prototype in-place rather than add a wrapping component - this leads to fewer surprises with users who put public instance or static methods on their component, and lets us keep the same kind of user-friendly API that looks like adding a new lifecycle hook.

To me then the nice thing about explicitly using react-mixin here is just that it makes it very clear to users that we are applying a mixin, so there's no question of whether a decorator or a wrapping function will hide methods.

In general I do believe HoCs are preferable for things like connecting to stores, but for cases like this and for pure render where I want to composably actually extend the behavior of a class, trait-style mixins are the best pattern available. Broadly I think the JS community is throwing out the baby with the bathwater here - most of the best modern type systems from languages like Scala and Rust broadly support traits, because they're extremely useful and expressive.

[ryanflorence]

Right now, just use createClass. Turns out it still works.

In the future, I'd like higher order components to replace all of our mixins.

[ryanflorence]

modify the prototype in-place rather than add a wrapping component - this leads to fewer surprises

Not sure that mutating object prototypes leads to fewer surprises than wrapping.

[taion]

I think it depends how you call into it. If you do something like

@decorate
export default class Foo extends Component { /* ... */ }

I don't care about the original class prototype at all, and I'd be quite surprised when I find out that the decorator hides my static methods and public methods (if it adds a wrapping component).

On the other hand, if you do

class Foo extends Component { /* ... */ }
export default createContainer(Foo)

then it's surprising to get the object prototype mutated.