Using React 16 to open new window with shared state (hackernoon.com)

It was pretty common to use https://github.com/tajo/react-portal for modals before React 16. It provided most (or all, I haven't really compared yet) of the functionality React 16 provides now so they've re-written it to just be a nice wrapper around the `createPortal` API.

Just use ReactDOM.render into a separate, top-level <div> that is usually empty. And then have the close button of the modal call ReactDOM.unmountComponentAtNode.

Alternatively, don't bother with all of this and just mount the modal into your children. Use CSS `position: absolute/fixed` to position it. Of course this assumes your ancestor elements don't have certain properties like `position: relative` or `transform` set, but this is usually not a problem.

Append the modal component to the react app element, and then change the app state to open it. The disadvantage is that your modal exists outside of the component that opens it, so you can't pass in props from parent to child. But as long as the triggering component and the modal have access to the same app state store it's not a problem, and fairly clean.

Can be useful when you have multiple monitors and don't want to clutter the main window, especially for single page apps or visualization/monitoring things.

I have done my own take at this since some times but vanilla only https://github.com/grz0zrg/wui where any of the dialog widget can be detached off the main window keeping the same content & state. A feature i never saw in any web apps but saw often on desktop apps, nice to see that some peoples think of this sort of thing with cleaner approach!

Portals can render your branch anywhere, inside the dom or outside in another. The cool thing is that it maintains current state, props and context, even when it's rendered elsewhere. That is insanely useful for common menus, overlaps, popups, annotations, when your container has overflow:hidden and you need to break out, etc. Used to be hacky or hard to realize, now all that's needed is returning a ReactDOM.createPortal(child, dom).

It's useful in enterprise apps.

You have three projects/clients/orders/enquiries/purchase orders/invoices/etc. You want to compare them/discuss them/etc.

You need to be able to switch between them.

It is very common for those kind of apps to get requests that lists/tables open a new window on link click.

The first thing that comes to mind is a gaming app where your main browser is the lobby but the windows are actual game instances. There's a site called global poker that does this for poker instances and it's clean / useful for this kind of use case.

Yes, I didin't read the whole thing so I don't know if it applies here, but portals have an additional property:

Events fired in the portal bubble up the vdom tree up to the component that mounted the portal (and then further upwards to the main vdom root), rather than up the real dom up to the popup window root.

That's establishing a separate component tree. This is one single component tree, hosted in the parent window. That was never possible until portals landed.

    <Parent>
      <MyPortal root={element}>
        <h1>Howdy!</h1>
      </MyPortal>
    </Parent>

Teah, it’s a clever (if not new) hack but there already exists a sane way of doing this

I will block react with ublock

Yeah, I use MessageChannel ports whenever communicating across domains: extensions, Workers, etc.

That was I can abstract it into convenience classes for connecting, event listening, etc.

I suppose the newer BroadcastChannel would be an option too, for high performance multi-window usage.

React has extremely careful versioning with a precise internal definition of what a "breaking change" is. Judging React by Angular's terrible version numbers doesn't seem fair to me.

They're on v16 because they increment the number any time they make a change that isn't 100% drop-in backwards compatible with the previous version, with a deprecation cycle when possible beforehand. Apps that function without deprecation warnings can update immediately when a new release drops.

Ultimately they are where they are because they were of a change they made when they released v15. Really, it's more like v3, but they kept the numbering consistent with how people talked about it. https://reactjs.org/blog/2016/02/19/new-versioning-scheme.ht...

honestly just caused me to realize I'm not even positive what version my last react app was in.. I thought I was 'current' but I know it was a single digit number so I guess I wasn't.

Major version numbers are now actually reflecting major changes. If you're reading an article for React 16 and have strange issues because you're on React 12, it's going to be a lot more obvious than if we're just bumping up minor versions. You can also be more sure that a if you're on 16.0.4, and the article is for 16.0.1 - that you're less likely to run into issues.

It's the same reason chrome is on 62 and Firefox is launching 57 at the end of the month.

Semantic versioning gets bigger numbers faster, but it's better for developers.

If you want to critize JavaScript, you don't have to make things up. It has real flaws.