Running two copies of React on a page can give errors because both use ID '.0'

[sophiebits]

Maybe we can do something smarter with the root index generation on the client side? Seems like this should work.

[chenglou]

Use the version number as a prefix could work? (You wouldn't have the same version of React twice, or else you didn't dedupe correctly).

[syranide]

This could solve itself when we drop IDs from the DOM (and be somewhat supported). As we would use an internal Map for translating node to instance (and the fallback property could be randomly generated). If we run with the data-react marker compromise and want to support multiple versions, data-react would also have to randomly generated.

However, for multiple versions to really play nice, we would probably (optionally) need to attach event listeners to the root nodes instead of the document (as I suggested for playing nice with other frameworks too).

[nathansobo]

We're planning to implement the Atom workspace views in React, so that packages can provide React components as panels and pane items.

Ideally, different packages could rely on their own independent versions of Atom so packages wouldn't break if we upgraded React in core. Am I correct in thinking that might be a little unrealistic? I don't imagine you guys plan on supporting interoperation between components written in different versions of React (thought that would be awesome).

So instead our plan is to export the instance of React we use in core for use by package authors in building their own views, so everything interoperates. The downside of this is that upgrading React in core could break packages. So we may need to supply a shim to old packages when that happens to ease the transition. Hopefully that won't be too difficult.

Just thought I'd share our use case, in case it shapes any design decisions as you change the API moving forward.

[sophiebits]

@nathansobo Atom plugins was what prompted this issue. :) We're not going to support using multiple versions of React seamlessly together in the near term, though it's possible it'll work in the far future. Until then, your best approach may be to have plugins populate iframes with plugin contents so that the scripts run in an isolated window.

[nathansobo]

I think we'll just give everyone a reference to the same React instance. The iframe approach is unfortunately too isolated for the kinds of things people are doing in packages. Hopefully we can shim API changes. Are you guys planning on a bunch for 1.0?

[syranide]

Multiple versions of React cooperating is technically not very advanced (#1939 (comment)). I think the biggest issue for now is that events handlers are always bound to the document, so events would not be playing nice at all.

Shimming is probably not going to be a viable strategy unless you're referring to maintaining a separate branch, but even that could probably turn into a major headache with some changes to come.

@nathansobo One possibility is to maintain separate Atom-branches of all major React releases, which does play well with multiple versions, it should generally not be that complex I think. It would probably be the more realistic approach, if any, I think. Although targeting different JSX versions is an interesting problem if that applies to you.

[nathansobo]

@syranide Interesting. Do you mean multiple numeric versions of React or multiple instances? I'm talking about a component from version 0.10 being embedded in a component tree from version 0.11. If that's something that could be possible, that would be amazing.

[syranide]

@nathansobo Multiple numeric versions of React, or any library for that matter. If I'm not mistaken, there are only two parts of React DOM that currently prevents this, the event system and DOM reactids.

1. Fixing DOM reactids is simple, the simplest solution being just suffixing ID_ATTR_NAME with a random/unique string on startup. Each React version sees only the DOM that is managed by itself.
2. The event system is a little more complicated, the problem is that all event listeners are bound to document, this does not play nice with other libraries (and event handlers). I've proposed moving event listeners to each mount root, which should be preferable as it would then also play nice with other event handlers/libraries. This is theoretically very simple, but does require a few lines of code so that the set of listeners is tracked per mount root instead and to prevent an event from being acted on multiple times by the same instance.

So, unless I missed something, that should be all that is needed to support multiple numeric versions of React. It does require maintaining a separate "Atom-compatible branch of each React version", but it should be possible to just rebase the fix onto each new version of React, without complications.

I don't know what the devs feel about # 2, but these are all rather simple fixes that I don't see why we wouldn't want to apply (one way or another) in the future.

But as I mentioned, I don't know if/how you use JSX today, but that is something that would also have to be available in a few different versions. There was one "breaking" JSX update a while back and it seems like there will be one or two more in the future.

[nathansobo]

Sorry, one more clarifying question. What you're saying makes sense with regard to multiple root components coexisting, but I'm still not clear on the scenario in which a parent composite component from one version of React owns a child component from another version.

Say for example I have implemented Atom's workspace in React and I also want to implement Atom's tree-view package in React. I was imagining that the tree-view component would be referred to directly in the workspace's render method and end up getting owned by the workspace. Isn't the contract between these components a bit more involved than just the React id's? What am I missing here?

[leoasis]

Regarding react ids with random suffixes, won't that break the reconciliation with server side pre-rendered react markup? Haven't looked at the internals of this, just wanted to make sure.

[syranide]

@nathansobo Fire away :)

I don't really have the full picture of what you're intending to do (so don't take my word for anything). As for my idea, one would have to use a "bridge" for rendering component of other versions, this could simply be a custom (generic) component that calls ReactVersionXYZ.renderComponent (this is roughly equivalent to how render() works internally).

Just something to visualize what I mean: (I assume that required React version is stored statically on the component class to be rendered)

render: function() {
  return (
    <div>
      <ReactBridge type={MyCompThatIsAnotherVersion} propA={1} propB={test'} />
    </div>
  );
}

So this would allow composition of components of different React versions (you own the instance of the bridge, not the actual component), but where the meat of each component should preferably depend on the same React version, everything should behave as you would expect (updates, callbacks, etc). However descriptors are version specific, so you couldn't pass unwrapped component classes or descriptors through the bridge and expect it to work. That is, the props you provide the component cannot be React-specific in nature.

Depending on how tightly you're integrating React, this could be a significant issue as batching wouldn't happen (by default) across such bridges/boundaries. It's definitely imagineable that one could rip out the virtual DOM/transactions out of React and have all versions of React cooperate, but I don't know if that is practical.

It most certainly is not as neat as using a single React version from top to bottom, but I think the merit of something like this is that each implementation ultimately becomes independent of whatever is on the other side. So when React 2.0 comes around, modules would simply adopt new versions as they please, rather than be abandoned.

But it also sounds like you might be integrating quite deeply with React and never being able to improve your API for React (as you would have to support each React version indefinitely) could be equally horrible.

Perhaps this is not at all applicable to what you have mind (if what I said makes sense :)), but you guys have an interesting problem at your hands, and I think a lot of it comes down to how long (or how far) you're willing to support "old addons".