unmountComponentAtNode about preact HOT 19 CLOSED

parent is the node you want to render into, root is the node that got rendered by your preact.render() call.

Here's a JSFiddle example: https://jsfiddle.net/developit/6ycn8ptL/

I should also add that you can do this using a wrapper component that returns null:

const Nothing = () => null;

let root = render(<MyComponent />, document.body);

// un-render:
render(<Nothing />, document.body, root);

from preact.

For "unrendering", I tend to do this:

render('', parent, root);

... but I agree that's a bit of a hack. If the implementation of unmountComponentAtNode is small enough, I will absolutely try to add it to Preact itself.

from preact.

Those hacks won't be needed anymore in the upcoming X version. You can use render(null, container) to clear a root and remove the dom reference from the vnode.

from preact.

Doesn't really matter what unrendering is beneficial for: seems like any lib that gives API to allocate memory should give API to unallocate memory too, out of common courtesy.

@developit You may not have a use case (maybe the things you mount into DOM are long-lived until the end of the web application, f.e. the tab is closed), but you don't expect everyone to have that same use case, do you?

Here's anither use case: a preact-vue adapter which is a Vue Component for mounting Preact components inside a Vue application would need to also clean up the Preact component when the Vue wrapper component is unmounted.

This kind of stuff is obvious! The API needs to obviously exist!

from preact.

I would like to add that an unrender would be beneficial for Hot Module Reloading as well.

from preact.

@rwwagner90 It's very rare that you need to explicitly destroy a root. Removing the parent DOM node should work just fine as long as you don't drag any vnode references around. Just read the linked issue on Shepherd and I'd be uneasy acting on assumptions alone. If there is indeed a memory leak it would show up in the devtools :)

from preact.

Definitely something that we should support at least in preact-compat, but for Preact itself I haven't yet seen a great use-cases for this. Please let me know if you have a compelling one though!

from preact.

Moved to preactjs/preact-compat#16

from preact.

At first it made sense to me putting this function into preact-compat, but what bugs me is that unmountComponentAtNode is the "opposite" of render, which in turn is part of preact (and we don't have to name that function like unmountComponentAtNode, that would be in preact-compat).

from preact.

@developit In that example, who is parent and who is root? I can use that hack for now (it's a hack, but it's just one line).
For instance, if I do this in a top level script:

preact.render(<MyComponent {...}/>, document.getElementById('my-real-dom-element'));

Then how do I use your "unrender" hack?

from preact.

Thanks, you are the man!

from preact.

We don't need hacks. Unmounting components in raw DOM is a very valid use case. Someone might be, for example, writing demos in React, Preact, etc, and will unmount them to mount other demos. You just don't know what people will do, and we don't want to encourage memory leaks (because that's what this is).

from preact.

The fix is simple!

function unrender(container) {

  const component = // figure out what root is currently rendered in container (keep track of it if you aren't)

  render('', container, root)
}

export default {
  ...
  render,
  unrender,
  ...
}

preact.unrender(someElement)

or similar.

Then add to README so people don't get confused and have to stumble here to figure it out.

from preact.

Hack are good for quick fixes but not long term. It would be very beneficial to have this in core preact, so other project leveraging it, don't have to introduce these workarounds :) this functionality is kinda critical for @skatejs preact rendrerer :) skatejs/renderer-preact#5 skatejs/renderer-preact#6

from preact.

How would it be beneficial for hmr?
we have working hmr and unrender would just cause flashing

from preact.

Is the correct solution still to use the hacks? I'm not sure if this is even something we should be concerned about in Shepherd or not, but the concern was raised in shepherd-pro/shepherd#517

from preact.

@marvinhagemeister isn't that the workaround suggested already? I'm also not sure if it applies to us in Shepherd or not. Could you help me understand when we need to render null and when we do not?

from preact.

@rwwagner90 That's not a workaround, that's the way to do it in Preact X :D We don't need any special unmountCompomentAtNode function like react does. Our compat shim just calls render with null under the hood.

Overall you only need to do this when you want to destroy a root where Preact rendered into. I can't comment on if it applies to Shepherd as I'm not involved in that project and thus have never used it.

from preact.

@marvinhagemeister can you say more about when you would want to destroy the root? Basically, in Shepherd we render the preact component into a DOM element for the tooltip, inside tippy.js, then when we end the tour, we destroy the tippy instance, which removes the tooltip elements, so the root the preact component was rendered into is effectively gone. The concern was just around whether or not we need to "cleanup correctly" to ensure we do not have memory leaks.

from preact.