[Q] onUnmount() behavior

[gaydenko]

Hi! README.md contains:

onUnmount()
The callback which will be invoked before a component is unmounted from DOM.

OTOH, let's look at the fragment in createComponent.js:

function unmountComponent() {
    this._isMounted = false;
    this._rootNode.unmount();
    this.onUnmount();
}

So, I'm wonder what is the onUnmount() behavior? Before? After?

And at the case intention is to call it before umounting (I hope :)), I guess it's signature must include a callback (common names for it are done or next) to permit async operations, say:

function onUnmount(el, next) {
  fetch('url').then(resp => {
    use(resp);
    next(); // real unmounting is triggered by this call!
}

Please, clarify a little :)

[dfilatov]

onUnmount will be invoked before the corresponding DOM node is removed or replaced. this._rootNode.unmount(); unmounts children.

[dfilatov]

What's the reason to put off real unmounting?

[gaydenko]

What's the reason to put off real unmounting?

@dfilatov , say, some visual effects want to keep the element in the DOM few additional hundreds of milliseconds.

[dfilatov]

It's interesting. There're can be some pitfalls. Right now I'm not quite sure it should be done via such way.

[gaydenko]

@dfilatov , I guess it is rather common idiom related to lifecycle. And it is close to your popular vow library (callbacks can be wrapped with promises) :)

[gaydenko]

@dfilatov , have you got some decision regarding this issue?

[dfilatov]

@gaydenko No, admittedly I haven't.

[dfilatov]

I have some contradictions here. If you want to apply visual effects inside onUnmount() you likely have to deal with DOM, for example, you need to change corresponding CSS class. But you shouldn't deal directly with DOM nodes, you should deal with virtual ones, so you need a way to call render() inside unmount. I feel something wrong here.

[gaydenko]

Yes, as far as you are currently inside virtual world of a virtual DOM, you probably have got a feel anything not-virtual is a crime :) Dealing with real not-trivial application (and using Trackira) I guess it is still very handy at some cases to deal with DOM directly rather via virtual DOM. For example, I use calendar, autocompletion (and some tiny others) widgets (no-no, no jQuery[UI]) dealing with DOM directly, as well as few life-cycle effects. And they work fine.

So, I would suggest to avoid too strict following this or that idiom, and to try to make a library friendly (technically speaking - neutral) to already existing tools.

[gaydenko]

I"m closing the issue as far as existing state is just a vidom view on the components.