is it a good idea to use `__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED`?

As I understand, React bindings of this package are using __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED variable from react package.

It looks a little bit dangerous, doesn’t it? It looks like it could break after any minor update of React.

Monkey patching of React internals looks are even more dangerous for me.

Is React bindings of suitable for production usage?

[Nicify]

“its-fine”

[CodyJasonBennett]

__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED is not guaranteed by the same semver as react or react-dom, but alongside internals like react-reconciler. This is why react and react-dom are updated in lock-step, with user-land implementations lagging behind to support a wide dependency range.

pmndrs/its-fine abstracts Fiber internals specific to react-reconciler since I found it annoyingly common for renderer authors to leverage internal fields to support different platforms (e.g. https://github.com/facebook/react/issues/14983, https://github.com/pmndrs/react-three-fiber/issues/43). By outsourcing this to an external package, we can focus on well-supported patterns and semver for interop. Here, we control the reconciler version.

This package has a different scope though. Signals introduce a new state primitive without explicit component bindings; __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED provides the mechanism to observe components as React sees them (these are shared globals and update via rapid mutation) and invoke hooks inside the context of that component. The latter is the most error-prone part since it does not follow rules-of-hooks (you can forget to update state), but I’ve covered withstanding issues with this implementation in #130.

In any case, having useSignal accept an actual Signal as outlined in https://github.com/preactjs/signals/issues/86#issuecomment-1239687550 enables it to do the same thing as the component bindings, with the safeguard that you’re working entirely within a component. My worry for this case would be tree-shaking of component bindings – you no longer need them and probably don’t want them. Is there a way to make this opt-in alongside a JSX transform (related: #115)?