[orb_yt]

Lovely. The file size reductions are quite surprising.

Removing the need to wrap sibling elements in a single parent element is a welcome change.

I'd be interested in hearing some use cases for using the Portal API.

Lastly, the new licensing announced last week was fantastic news. I commented on last weeks thread, but I want to extend another round of compliments to Facebook and the React community as a whole for prompting this change. Props to them.

[humblebee]

We use portals quite a bit in our application and they always are a pain to test. This is what excites me the most about React supporting them natively. Hopefully this means that enzymejs will be able to easily walk down and seamlessly jump into a different part of the DOM without having to use references to adjust.

Portals are helpful when using content overflow in modals. For example, we have a modal which contains a form and that form has an autocomplete text box. When we render the autocomplete part, we need to render it outside of the modal, otherwise the overflow policy blocks the contents and does not allow the autocomplete are to appear over / outside of the modal.

The use of portals also make it easier to support screen readers through the aria tags by allowing the application to quickly block the background of the application and allow the screen reader to focus on the content presented to the user.

[danield9tqh]

This does worry me a bit though. There is probably a reason they are difficult to test, because they go against the React DOM pattern of a component only having control over the DOM nodes inside it. Call me a purist but this seems like a deviation from React's functional roots and going against the very problem React was trying to solve in the first place.

[danabramov]

The feature is mostly intended for rendering into nodes not managed by React. Such as a document child that is sibling to the application root.

[maaaats]

That may be true, but not having this possibility has made react near unusable for a lot of common UI patterns on the web.

[AgentME]

The portal API sounds great for modals and dropdowns. It looks like a good fit for react-float-anchor[0] (used by the more interesting to look at react-menu-list[1]). I'm currently abusing `componentWillReceiveProps` to get portal-like behavior, but it means that test code has to do react-float-anchor -specific things in certain situations to see elements rendered in it.

[0] https://github.com/StreakYC/react-float-anchor [1] https://github.com/StreakYC/react-menu-list

[ryanbertrand]

We use ad hoc portals for showing modals, flyout panels, popovers.

[audessuscest]

Do you know where to find some usage examples ?

[captnasia]

If you go to the Portals documentation ( https://facebook.github.io/react/docs/portals.html ) you can find some examples throughout.

[teraflop]

Both of the CodePen example links on that page are insidiously broken. The demos appear to work, but they don't actually demonstrate the claimed portal functionality at all:

    // These two containers are siblings in the DOM
    const appContainer = document.getElementById('app-container');
    const modalContainer = document.getElementById('app-container');

Note that both variables refer to the same element.

[danabramov]

Sorry, there was so much to do in the release that some issues crept into the new docs. We'll fix them soon. :-)

[acdlite]

Fixed now! Thanks for the bug report!

[teraflop]

No problem! And on re-reading my comment, I probably shouldn't have used the word "insidiously", it came off a lot more negative than I intended. Thanks for the quick fix.

[maaaats]

I've used portals to make modals, as they often have to be close to the root. This has had many quirks and bugs from code not expecting to be in a portal, hopefully it being a supported concept fixes this.