is it safe to use __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?

[Eliav2]

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 libraries.

1. is it safe to use in development?
   for example using React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED.ReactCurrentOwner.current.type.displayName I could warn the user the name of the component that consumed a custom hook without wrapping it with required context.
2. is it safe to use in production? for example this use case.

thank you.

[gaearon]

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.

I could warn the user the name of the component that consumed a custom hook without wrapping it with required context.

If you use console.error and the user has React DevTools then they should already see the component stack in development automatically. That’s the intended solution.

is it safe to use in production? for example this use case.

No, the linked answer will most definitely break. It’s not clear to me what was the original problem that the author tried to solve, but there are almost always better ways to approach it.

[Eliav2]

@gaearon thank you for the response, however,

1. the solution you suggested don't show the component name in my case because the error would be raise from event and not a lifecycle event. means I save the ReactCurrentOwner (using useRef) and if the context is not there when the event is triggered I use it.
2. I looked at some previous releases of react and it seems like the structure of __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED is almost identical.
3. there some really popular libraries out there using this hook internally like wdyr. and it doesn't look like this lib releases a patch for any single release of React. if you insist prop should be accessed, how things keeps working even on different

We offer no guarantees about what will happen if you access things there.

Why don't you provide stable API for some internal state of React itself so developers could potentially do anything they want with it (without annoyingly forking and losing any feature updates)?

[gaearon]

however

You asked a question (“is it safe”), I provided a response (“it’s not”). If you choose to ignore this, it’s your decision, but we provide no guarantees. I don’t know what else to say here.

Why don't you provide stable API for some internal state of React itself so developers could potentially do anything they want with it (without annoyingly forking and losing any feature updates)?

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.

[Eliav2]

thank you, @gaearon,
how can I file RFCs for such proposals?

[gaearon]

Sure! In the RFC repository.

[martonlederer]

Favorite issue so far

[zlodo]

quintessential web developer mindset right here

[benjamin-bader]

As an Android developer, I feel this question so hard

[gaearon]

let's not spam people.