How to *destroy* a portal? about react-reverse-portal HOT 3 CLOSED

Thanks so much for your thoughtful comments @pimterry.

I started out on this path as I noticed that the portal containers in some examples are managed through direct DOM intervention. So I thought, well, how about portals themselves.

I now think of portals as components with normal react attributes, except they don't appear in the DOM, just the virtual DOM. To make this directly manageable, I create a portal list (cache), and wrap that around individual portal wrappers, which contain the portals (InPortal).

const wrapperstyle = {display:'none'} // static

// hidden portal wrapper for clarity and usage of conventional react relisting services
export const PortalWrapper = ({
    portal, index,
}) => {

    return <div data-type='portalwrapper' data-index = {index} style = {wrapperstyle} key={index}>
        {portal}
    </div>

}

// portal list component for rapid relisting of updates, using external callback for set state
export const PortalList = ({scrollerID}) => {

    const [portalList, setPortalList] = useState(null)
    const isMounted = useIsMounted()

    useEffect(()=>{

        scrollerPortalCallbacks.set(scrollerID,
            {setListState:()=>{
                isMounted() && setPortalList(scrollerPortalListData.get(scrollerID).portalList)
            }})

    },[]) 

    return portalList
}

Note that the portal list can be refreshed from outside (a portal manager), whenever the list is updated. This takes advantage of React's normal (fast!) refresh capability.

The portal list is embedded in a high level component (but hidden) to activate the portals.

    return <div data-type = 'scroller' data-scrollerid = { scrollerSessionID }>
        <div data-type = 'portalroot' style = { portalrootstyle }>
            <PortalList scrollerID = { scrollerSessionID }/>
        </div>
        <Viewport
            ...

The OutPortal is pulled into its display shell like this:

    portalchildRef.current = useMemo(()=>{

        if (portalStatus != 'render') return portalchildRef.current

        portallistitem.reparenting = true
        let reverseportal = portallistitem.reverseportal

        return <OutPortal node = {reverseportal} />

    }, [portalStatus])

    ...

    return <div ref = { shellRef } data-type = 'cellshell' data-scrollerid = {scrollerID} data-index = {index} data-instanceid = {instanceID} style = {styles}>
            { (portalStatus == 'render') && portalchildRef.current }
        </div>

All this seems to be quite stable and performative. Note that I keep and pass around your portal metadata (reverseportal).

Thanks so much for your tool Terry! It's brilliant, and a life-saver.

from react-reverse-portal.

Oh, and to be clear, the portal is destroyed when its wrapper is destroyed.

from react-reverse-portal.

As far as I know, there's no specific steps required.

First you'll create a portal node, and one or more InPortals and OutPortals and use them. Once you're done, the In/OutPortals will be unmounted by React (which cleans up their DOM state) and then they'll be garbage collected, and the portal node will be garbage collected as soon as your own code doesn't hold a reference to it anymore (which is necessarily after the various portals have been collected, so the DOM has been cleaned up by this stage).

React-Reverse-Portal doesn't track any persistent state outside those objects, so once they're not referenced as far as I'm aware they're gone.

I'm not super knowledgeable about how fibers reference portals internally, but as far as I know there's no need to get involved with the internals of that. There's no documented need to manually clean up portals, and any issue there sounds like a memory leak in React in general.

Is there a specific behaviour you're seeing where this doesn't happen? If you have a reproducible leak I can look at that would be very interesting.

from react-reverse-portal.