Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add setter for the ID_ATTRIBUTE_NAME to top-level React #4669

Closed

Conversation

dvdplm
Copy link

@dvdplm dvdplm commented Aug 20, 2015

To facilitate use-cases where multiple React apps are running on the same page,
expose the DOMPropery ID_ATTRIBUTE_NAME on the top-level React object and make
ReactMount reference the propery from DOMPropery rather than its own local copy.

This is most probably not the right place to add something like this, so feedback
with suggestions is most welcome.

This is based off master (currently 0.14-beta3). Issue with background: #1939

To facilitate use-cases where multiple React apps are running on the same page,
expose the DOMPropery ID_ATTRIBUTE_NAME on the top-level React object and make
ReactMount reference the propery from DOMPropery rather than its own local copy.

This is most probably not the right place to add something like this, so feedback
with suggestions is most welcome.
@sebmarkbage
Copy link
Collaborator

The biggest problem when this happens is when you have two different Reacts that are unaware of each other. I.e. two different npm packages. Perhaps even of the same package and maybe even same version. It seems difficult for these two coordinate the ID even if they could set it manually.

It'd be better if we could auto-gen this ID so that it is unique. However, if a tree is server rendered, these IDs are already in use so that pattern have to be picked up potentially.

Another solution is something like we added in 0.14 where we look up the root ID to see if it belongs to this React and otherwise ignores it.

@sophiebits
Copy link
Contributor

#1939 is closed so we shouldn't need this any more. If more issues pop up we can address them separately.

@sophiebits sophiebits closed this Oct 6, 2015
@hakunin
Copy link

hakunin commented Mar 31, 2016

Right now it seems impossible to change ID_ATTRIBUTE_NAME, many say they had to fork the repo.
It might be due to the other file caching the value of ID_ATTRIBUTE_NAME so that when its changed, it still looks for the old one (which is fixed with this PR).

I think this should be reopened and fixed on v14.

@gaearon
Copy link
Collaborator

gaearon commented Mar 31, 2016

Is there any particular problem that prevents you migrating to 15? We’ve been delaying 15 for a while now and really want to get it out. RC2 should be solid enough for you to try adopting.

Spending more effort on 14 branch right now is possible but will negatively affect development of 15.x, especially as it may introduce more issues which are not even relevant to 15 anymore. What do you think?

@hakunin
Copy link

hakunin commented Mar 31, 2016

I upgraded to v15 and also tried this fix and unfortunately the fix didn't work in my case (collision with Grammarly) so I am all for releasing v15.

@gaearon
Copy link
Collaborator

gaearon commented Mar 31, 2016

👍 Stay tuned, it’s coming soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants