Component with mixins: componentWillUnmount should be called in reverse order (of componentDidMount)

[rickbeerendonk]

componentDidMount() and componentWillUnmount() allow for DOM manipulation outside React's reach. DOM manipulations done in componentDidMount() should be undone in reverse order in componentWillUnmount(). This is currently not possible in components with mixins (see footnote) due to the order in which the events are fired:

Current order:

1. mixin1.componentDidMount()
2. mixin2.componentDidMount()
3. component.componentDidMount()
4. mixin1.componentWillUnmount()
5. mixin2.componentWillUnmount()
6. component.componentWillUnmount()

Correct order:

1. mixin1.componentDidMount()
2. mixin2.componentDidMount()
3. component.componentDidMount()
4. component.componentWillUnmount()
5. mixin2.componentWillUnmount()
6. mixin1.componentWillUnmount()

JSFiddle: http://jsfiddle.net/rickbeerendonk/3cm3sso5/

Full lifecycle example: https://github.com/rickbeerendonk/react-om-examples/blob/d59eda2b67e07d345a44f9552a2ab231b4127f8a/Extra%2002a.%20ComponentLifecycle%20with%20Mixins/jsx/index.html

Footnote: If all the mixins and the component with those mixins are manipulating the DOM.

[gaearon]

Curious to hear your use case! I don't usually find myself depending on the order of mixin lifecycle hooks.
What kind of DOM manipulation do you perform in mixins?

[yiminghe]

Other mixin mechanisms such as YUI widget extension is same as @rickbeerendonk proposed, it is more reasonable.

[rickbeerendonk]

@gaearon componentDidMount() can be used for constructing purposes. componentWillUnmount() can be used for destructing what was constructed in componentDidMount(). If a component builds on something a mixin has already constructed, it should be removed before the mixin additions are removed. Destructing should be in the reverse order of constructing.

[syranide]

It's mentioned briefly in #1853 if I understand you correctly (just mentioning for posterity).

[zpao]

Hmm, we opted for deterministic ordering of calls instead of special casing any specific lifecycle methods (see #1601). I totally get where you're coming from - we should consider this. cc @yungsters who originally proposed what we did in #1601.

[gaearon]

To clarify, the point of #1601 was protecting against

mixins: [A, B],
componentDidMount () { }

behaving differently from

componentDidMount () { },
mixins: [A, B]

[sophiebits]

I think I'm in favor of this, though it's not obvious what order all the update methods should be called in when the mixins are interdependent.

[rickbeerendonk]

@spicyj The main issue here is giving control back to the developer. Interdependent mixins can be left to the developer. Just do componentDidMount() in the order the mixins are given up (just like now), but reverse the order for componentWillUnmount() (see the example at the top).

[yungsters]

Sorry, did not see this until now. I am in favor of @rickbeerendonk's proposal. We should effectively reverse the order of componentWillUnmount(), so:

var MixinA = {mixins: [MixinA1, MixinA2], ...};
var MixinB = {mixins: [MixinB1, MixinB2], ...};
var Component = React.createClass({
  mixins: [MixinA, MixinB],
  ...
});

// Depth-First Traversal of Mixins
// MixinA1.componentDidMount
// MixinA2.componentDidMount
// MixinA.componentDidMount
// MixinB1.componentDidMount
// MixinB2.componentDidMount
// MixinB.componentDidMount
// Component.componentDidMount

// Reverse of Above Traversal
// Component.componentDidMount
// MixinB.componentWillUnmount
// MixinB2.componentWillUnmount
// MixinB1.componentWillUnmount
// MixinA.componentWillUnmount
// MixinA2.componentWillUnmount
// MixinA1.componentWillUnmount

The intent of the lifecycle methods is for componentDidMount and componentWillUnmount to mirror one another. Resources allocated or state mutated in the former should be reversed in the latter. As such, mixins that assume a particular state when mounted should be able to assume that same state when unmounting.

We're conceptually matching curly braces / HTML tags / etc. here.

[sophiebits]

See discussion on #3290 – mixins are effectively a legacy feature now and so I'm not going to merge my (breaking) change to their behavior even though I agree that it makes more sense that way. Closing as wontfix -- in most cases you can use higher-order components to get the behavior you want.