-
Notifications
You must be signed in to change notification settings - Fork 46.8k
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
Rename react/lib/* to react/private/* #6460
Comments
I still like the |
While we have been telling this to people, the reality is that a lot of people (me included) thought it was relatively safe some time during 0.12, and there is a bunch of components whose authors don't know this needs changing. Renaming it for 16 would serve as a good warning for any existing components, as it would effectively force authors to explicitly opt into using "private" parts or find workarounds. |
We could go all in and really obfuscate it. Some hash or something that gets added to our build pipeline and changes for every major release.
|
👍 |
Nah, shouldn't do it on every build. I thought about it but that would probably screw our own packages so we need some reliability (eg react-dom 15.0.0 should be able to use react 15.0.1). |
Our own packages should have a way of accessing the internals needed, using private API like SECRET_DOM, without indexing into lib. That has the added bonus of allowing addons to be put into separate UMD builds. |
while there isn’t a defined, documented API for accessing internals to create a renderer, this change will greatly hinder all the experimentation taking place in the custom react renderers community. While that is a known experimental use case where things will break (I believe maintainers and users of these renderers understand this), removing that capability or hiding it in a system like md5 hash names would be detrimental in my view. |
I feel like people experimenting should check out the React repository anyway, rather than relying on an NPM build. Maybe I'm wrong, curious what @gaearon thinks about that point. |
Depending on how we did it, I don't think it would really hinder experimentation. You would just be forced into knowingly using non-public APIs and if we went down that hash per major route, you'd just have to update paths for a major version. We'll definitely keep the use case in mind though. And you're paying attention so I'm sure you'll chime in (or I'll reach out) if we make any drastic changes that would be unrecoverable. |
Building it and then doing something like
Something like |
I’ve thought about this a bit more over the weekend and am currently opposed to this. The reasoning against this is:
|
An API that could satisfy everyones needs: const reactLibHash = require('react/libHash'); // e.g., "M0D3F"
const libIWanted = require(`react/lib/${reactLibHash}/ThingIWant`); This would let you use the hashing method, while still allowing people to get the things they want from libs. But making it awkward enough that it should hopefully be only used when actively sought after. Not documenting it could help with that. Downsides are that it doesn't work with the Ultimately, I agree with @iamdustan on every point. It seems like a user problem more than your teams problem. If somebody wants to depend on an internal item and it gets removed in the next version, then it's up to them to handle that situation over you guys. That's an OSS-wide issue, not just a react issue. |
Agree completely with @iamdustan as a custom renderer author. Currently it is necessary for my project to use react internals and I am aware that it may break even with patches or minor updates to react but that's something I can handle for now. Having build specific hashes would just make it a bad experience for almost everyone. Naming it "private" instead of "lib" will make it more apparent that things may break so that's good enough in my opinion. To solve the real problem at least in my case is to find out why the third parties are trying to use private parts of react. To be even more specific, I am seeing great progress towards separation of DOM and react, and for react three renderer, with every update, fewer private react parts need to be used. Eventually when react dom is completely separated we will be able to look at it and see how it works as an independent entity and if it does not touch react private parts then it will be very comfortable for other custom renderers to appear and be more stable. I am guessing that eventually the same may happen to the other popular private parts, I guess they may need to be exposed in the stable api or modularized. Or third parties could be poked. Poke us but don't punish us :) |
Another factor to consider. There are recordings of you guys considering Enzyme to be officially supported as a community based library for testing React. There are parts of Enzyme that currently require reaching into react. So either we would need to work together on some of that, or need continued access into the internals. Example: |
Yeah, absolutely. From the related core notes:
We understand this is the case now, too. We’ll be keeping this in mind as we figure out the strategy for how to move further with #4230 without breaking everyone. |
@gaearon If that's the case, doesn't it make more sense to just call it |
It's worth noting that this is only relevant as long as we use |
As suggested on Twitter.
Let’s do it so we don’t get more broken components?
The text was updated successfully, but these errors were encountered: