Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?
-
is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ? · Issue #3896 · reactjs/react.dev
I want to use the undocumented property React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED which holds some interesting insights and can be useful in some cases. I'm developing React libr...
-
@Gern_Blaanston
On being told "No, it's not safe; it could break in any release. That's why it has the scary name", the OP went on to say,"...However, ... I looked at some previous releases of react and it seems like the structure of
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIREDis almost identical."Almost is close enough, right? It does change but it won't change in a way that will break what I'm using it for.
-
They should create on open issue (that rolls from release to release) that randomly changes that property to purposely screw with people who use that.
-
@Watson said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
Almost is close enough, right?
In javascript almost is all you can pray for.
-
@Watson said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
Almost is close enough, right? It does change but it won't change in a way that will break what I'm using it for.
That's actually something where I can sympathise with both sides of the argument, having been on them on different occasions.
Sure, you don't want people to use code that "could break in any release." OTOH, sometimes code that "could" change has actually been the same for years or decades and while, OK, sure, maybe one day it will change, it's not quite the same status as "we are in the process of changing that code right now." Sometimes developers are wary of making a feature "official" for fear of not being able to change it if they need later, but actually the feature is fine.
(though of course it seems the most common problem nowadays is more the opposite, people changing base stuff willy-nilly, but still)
So yeah, I get that the OP would ask "it's marked 'do not use' but how unstable is it really?" and that the boilerplate answer of "it's marked 'do not use' so do not use" is unsatisfying. But again, I also get that the dev would say "do not use" because they don't want to commit to supporting it.
-
The dev's answer should have been more like:
No, it isn't safe. If you have a use-case for a valid use for some of the information in there, let us know (describes how), and we can add it in a supported structure. It has a scary name like that so we can change it whenever we need to, or even just because we're in one of those moods, but because you don't want to be fired (for using secret internals with a scary name and letting your web app break), those changes won't affect you.
-
gaearon's answer was pretty close to that, actually:
No, it’s not safe to use. That’s why it has a scary name. We offer no guarantees about what will happen if you access things there. The behavior can change on any release. We strongly recommend against touching it in your library if you don’t want that library to break later.
And then:
You’re welcome to ask for specific features as a public API in separate issues that describe specific use cases. You’re welcome to file RFCs for these proposals.
The only thing really missing was pasting the link to the RFC repo, imo.
-
@Watson said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Gern_Blaanston
On being told "No, it's not safe; it could break in any release. That's why it has the scary name", the OP went on to say,"...However, ... I looked at some previous releases of react and it seems like the structure of
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIREDis almost identical."Almost is close enough, right? It does change but it won't change in a way that will break what I'm using it for.
My response there would be "Well, now we know you're trying to use that part we'll make sure to break it in the near future. There will be no announcement of this." It's like how if a machine is a test machine, it absolutely must not have production services deployed on it, and the services that end up on it need to be purged from time to time just to make sure that no production workflows end up depending on something intended to be highly unreliable.
-
@remi said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Watson said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
Almost is close enough, right? It does change but it won't change in a way that will break what I'm using it for.
That's actually something where I can sympathise with both sides of the argument, having been on them on different occasions.
Sure, you don't want people to use code that "could break in any release." OTOH, sometimes code that "could" change has actually been the same for years or decades and while, OK, sure, maybe one day it will change, it's not quite the same status as "we are in the process of changing that code right now." Sometimes developers are wary of making a feature "official" for fear of not being able to change it if they need later, but actually the feature is fine.
I get that. For many years, PHP's basic CRUD functions for PostgreSQL were noted as EXPERIMENTAL in the documentation, even though those functions were stable enough for production use. So stable, in fact, that the documentation hadn't needed updating for all those years. So no-one bothered, which is why the note remained so long.
-
@dkf said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
It's like how if a machine is a test machine, it absolutely must not have production services deployed on it
A while back, I built a server-side bit of a project that was called by a colleague's client-side bit. I unit tested it and deployed it to one of our test servers.
Last week, I got a bug report that one of the users said it wasn't working properly. When I read the bug deeper, it became evident to me that the project team had "deployed to production"... but only the client-side. The client-side guy pointed the production client to the test version of the server-side component. Since the service only provided a processing service and accessed no data, it "worked just fine".
-
@Watson said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
Almost is close enough, right? It does change but it won't change in a way that will break what I'm using it for.
The current rationale is "We will be able to accomplish our goal faster and cheaper if we do this thing. I'm confident that the future cost of dealing with breakage will be less than the savings."
Everyone has seen this argument made, and it's really tempting to management. However, we've also all seen "Why did these idiots build this thing that way? I was going to make a minor modification, but now I have to fix all these hacks just to get it to build."
This is simply how technical debt gets created. It's almost always wrong. Ironically, the teams most likely to choose to incur the debt are the teams most likely to be hit hardest by the consequences. Mature teams with unit tests, automated builds, and that touch all of the projects very often (at least for component updates), can handle some amount of debt just fine. Teams that only touch code when someone asks for a change are much more likely to find nasty surprises.
-
@Zecc True, but it should have been one answer (the first), not a sequence of back-and-forth.
-
@Jaime Test servers shouldn't be reachable from the general Internet. For internal-use tools, they shouldn't be reachable from the general-user part of the network.
-
@Steve_The_Cynic
I agree. However, in this case it's client software so the communication path is:(Prod client) -> (test server)
Since we are lazy enough to test on the same computers we work on, this path would be open so that testing could be accomplished, since (Prod client) = (Test client).
-
@Gern_Blaanston the only correct answer to that question is "CAN YOU FUCKING READ YOU FUCKING JS MUPPET?!"
-
@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Jaime Test servers shouldn't be reachable from the general Internet. For internal-use tools, they shouldn't be reachable from the general-user part of the network.
It really depends on what you are testing, and what other constraints there are. The only things that differentiate a test deployment from a production one should be the stability of promises associated with it, and the amount of resources allocated. Test stuff is like a yoyo; it goes up and down on a shoestring.
-
@Gern_Blaanston said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ? · Issue #3896 · reactjs/react.dev
I want to use the undocumented property React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED which holds some interesting insights and can be useful in some cases. I'm developing React libr...
"Yes, currently. Have a great day!"
-
@MrL said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Watson said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
Almost is close enough, right?
In javascript almost is all you can pray for.
Wish
-
@Jaime said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
Teams that only touch code when someone asks for a change are much more likely to find nasty surprises.
More to the point, they aren't going to take time out occasionally to change this ugly thing they keep tripping over (but never have an explicit request to change) so that it's less ugly and poses less of a trip hazard.
I believe the "Antipatterns" book called this particular malady "Lava flows".
-
If I were the library owner, I'd consider writing a build script to auto-rename the property throughout on every build.
-
@PleegWat At a certain point, putting in more effort to keep people from using footguns just isn't worth it. These people probably don't ever upgrade anyways.
-
@Unperverted-Vixen or they will create a "polyfill" that decodes the renaming algorithm...
-
@Unperverted-Vixen And if they use the footgun and they do upgrade, and the upgrade blows their foot off (all the way up to the armpit, it's that sort of footgun), well, they had it coming.
Especially if the footgun has a name like
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED...
-
@Steve_The_Cynic that is not how the JS community works, though. You can still build that foot gun even with that honking great warning on it and it’ll still be upstream’s fault when it breaks.
-
@Arantor Not just JavaScript in my experience. If only object-oriented (yes, I know) languages had a keyword for saying that this piece of an object is reserved for the object to use. You could even use "private" as that keyword... (I've heard rumours that some OO languages even have such a thing, but I'm not sure I believe anyone's that smart any more.)
-
Private properties - JavaScript | MDN
Private properties are counterparts of the regular class properties which are public, including class fields, class methods, etc. Private properties get created by using a hash # prefix and cannot be legally referenced outside of the class. The privacy encapsulation of these class properties is...
-
@Arantor said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Steve_The_Cynic that is not how the JS community works, though. You can still build that foot gun even with that honking great warning on it and it’ll still be upstream’s fault when it breaks.
It's always someone else's fault, and the upstream just presents itself as an easy to blame party.
People who can admit some things are their fault usually also can learn from their faults and go program in something saner.
-
@Steve_The_Cynic modern JS even allegedly sports those features now. But at least with things that are private properties and you having to go out of your way to use reflection, those other languages have people who do ask “actually am I in the wrong here?”
But JS has such a culture of not using these that it’ll take them a while to unlearn.
It’s not like PHP didn’t have the exact same journey ~15 years ago… nosiree this has never been encountered by anyone anywhere before!
-
@Steve_The_Cynic Is this "private" thing that you mention a bit like using "__" in Python?
-
@error Huh. TIL. Thanks.
-
@cvi said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Steve_The_Cynic Is this "private" thing that you mention a bit like using "__" in Python?
That reminds me when I wrote a plugin for
ansibleand I needed some information which was private... in an object that was not passed to the plugin as an argument...So I have iterated through the stack, found a method call that did have the correct argument and then extracted the information.
I suppose when it comes to foot guns, this is a howitzer.
-
@cvi said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Steve_The_Cynic Is this "private" thing that you mention a bit like using "__" in Python?
Well, it probably has to generate some key to store it under, but it does not say what the key is. My guess would be it generates a
Symbol()and stores it in the closure of the constructor so you really don't have a way to know it from outside the class. At least that would be an obvious way given they've already introduced thisSymboltype and used it to add some magic members without risking they'd conflict with existing identifiers.
-
@Bulb said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
It's always someone else's fault
: "Doctor, why does it hurt when I chop my leg off with a rusty band-saw?"
: 
-
@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Unperverted-Vixen And if they use the footgun and they do upgrade, and the upgrade blows their foot off (all the way up to the armpit, it's that sort of footgun), well, they had it coming.
Especially if the footgun has a name like
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED...Just had a thought... Rename that object to add a little more each time...
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED_FROM_A_CANNON__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED_FROM_A_CANNON_INTO_THE_SUN
-
@dcon said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Unperverted-Vixen And if they use the footgun and they do upgrade, and the upgrade blows their foot off (all the way up to the armpit, it's that sort of footgun), well, they had it coming.
Especially if the footgun has a name like
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED...Just had a thought... Rename that object to add a little more each time...
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED_FROM_A_CANNON__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED_FROM_A_CANNON_INTO_THE_SUN
Yeah, but that way you end up with __REAL_SECRET_FOR_SERIOUS and make PHP look good
-
@izzion said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@dcon said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Unperverted-Vixen And if they use the footgun and they do upgrade, and the upgrade blows their foot off (all the way up to the armpit, it's that sort of footgun), well, they had it coming.
Especially if the footgun has a name like
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED...Just had a thought... Rename that object to add a little more each time...
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED_FROM_A_CANNON__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED_FROM_A_CANNON_INTO_THE_SUN
Yeah, but that way you end up with __REAL_SECRET_FOR_SERIOUS and make PHP look good
JS already make PHP look good.
-
@izzion blame the MySQL folks for that one, it's part of the MySQL C client library.
-
@Arantor said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@izzion blame the MySQL folks for that one, it's part of the MySQL C client library.
mysql_make_javascript_look_real_good()?
-
@dkf
mysql_make_javascript_look_real_good()actually.
-
@dkf Followed by
mysql_really_make_javascript_look_real_good()?
-
@Steve_The_Cynic people using the MySQL client library itself are at least writing in a “real” programming language that doesn’t tolerate all manner of bullshit that people can just muddle through until it sort of works and that’ll be fine.
-
@Arantor said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@dkf
mysql_make_javascript_look_real_good()actually.
-
@dkf said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
mysql_make_javascript_look_real_good()?@Arantor said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@dkf
mysql_make_javascript_look_real_good()actually.WIll the real
mysql_make_javascript_look_real_good()please stand up?
-
@dkf I’m ill and thought I was being funny adding a real where I didn’t see one.
-
@Arantor I'd guess it's in C, which tolerates exactly none of that sort of nonsense, especially anything derived from "It's not my job to think"(1)...
(1) My response to that would be something along the lines of, "Yes, it very much is your job to think. You're a programmer, so you have to, well, program, which means you have to think about what you're doing."
-
@Steve_The_Cynic correct, the client library is indeed in C where the sorts of BS that infests JS absolutely doesn’t fly.
-
@Arantor said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@dkf I’m ill and thought I was being funny adding a real where I didn’t see one.
This is why you should never trust someone with a sick sense of humor.
-
@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
You're a programmer, so you have to, well, program, which means you have to think about what you're doing.
-
@dkf said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
@Steve_The_Cynic said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
You're a programmer, so you have to, well, program, which means you have to think about what you're doing.
I know lots of them don't, but I stand by my assertion that it's an essential part of the job.
-
@Arantor said in Is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?:
in C where the sorts of BS that infests JS absolutely doesn’t fly.
I guess that's
, as in it tolerates its very own unique brand of bullshit, which then might even provide useful password recovery features and surprise extension APIs.
