react-focus-lock
react-focus-lock copied to clipboard
"FocusLock: could not obtain ref to internal node"
Hi, currently I'm using v2.1.0.
When I upgrade to v2.1.1 and upwards, the FocusLock works still fine. But when I update my jest-snapshots I get the following output:
console.error ../base/node_modules/react-focus-lock/dist/cjs/Lock.js:133 FocusLock: could not obtain ref to internal node
Do I need to make adjustments while upgrading? Please help
That message was added in 2.1.1. You had a problem before, it was just not reported.
The problem is quite fatal actually - FocusLock needs a DOM node to work with. If it's actually works - then it's not getting in on FocusLock mount, but later. Could it be a case?
I'm experiencing the same issue. The issue only happens in the test spec files. (using react-test-renderer
)
In my test I see no reason why FocusLock would miss the DOM node.
even this will throw the same error inside a test file:
<FocusLock>
<div>test</div>
</FocusLock>
🤷♂️. To be solved among with #125
I guess that is not solved, this error is actual with latest 2.9.1 version
Sounds like I should add at least one RTL-backed test
any updates on this issue?
Unfortunately, I am still not able to reproduce this particular problem.
If you are experiencing this problem - please suggest a broken test.
I recently ran into this error message while creating a snapshot with the "react-test-renderer" renderer. The renderer will simply convert any provided components to pure javascript objects, and without depending on the dom.
Since there is no dom this means our DOM node never gets attached to the .current, which leads us to our error statement.
The solution is to manually create the element.
function createNodeMock(element) {
if (element.type === "div") { // The Container's "as" prop is set to a "div" as default.
return document.createElement("div");
}
}
const tree = renderer.create( <ReactElement / > , {
createNodeMock
});
So that is more synthetic use case rather than a real "bug".
I will correct this message to trigger only if a custom container
is used - that would suppress message for all "standard" usecases, but leave it in place for moments when it can be actually useful.
Appreciate it!
Resolved in v2.9.2