`node._owner` is too unstable
kthjm opened this issue · 9 comments
#4 is insufficient. node._owner is not always null.
return ReactElement(
type,
key,
ref,
self,
source,
ReactCurrentOwner.current, // ← become _owner directry
props,
);var ReactCurrentOwner = {
/**
* @internal
* @type {ReactComponent}
*/
current: (null: null | ReactInstance | Fiber),
};node._owner is so unstable that it is new ReactCompositeComponentWrapper at my local. so can't use it for detect.
React own detect its element by isValidElement function use Symbol, But i don't know whether hast-to-hyperscript relate it better.
sorry for the confusion. my did was superficial.
Can’t you check for '_owner' in node?
No, I mean replace node_owner === null with '_owner' in node.
r became true ok.
Last question:
Why would this ever fill _owner?
Lines 175 to 176 in c7162d2
What is a ReactCompositeComponentWrapper and why is it set?
i examined but couldn't clarify the situation.
- run same process in just node.js,
_owneris null in both enviroment. - above image code bundled in 'production', and run in browser,
_owneris null.
above image situation is run by webpack-dev-server with webpack.HotModuleReplacementPlugin in browser, So the cause may exist in HMR i think.
But sorry, im not sure and i have no idea.
Please don't rely on _owner, it's an implementation detail and might change behavior in future releases. Generally anything with underscores that isn't documented in public API docs isn't a public API ;-)
It’s been there for more than a year. While true, we could also add other checks when React changes, IMHO. I’d say just go for '_owner' in node now!
ok.
thanks and sorry for a fuss. I am glad to be able to use hast comfortably.
or do i PR? no need?
