Component selector should be Flare compatible
bvaughn opened this issue · 9 comments
DevTools currently relies on preventDefault
and stopPropagation
to prevent the selector tool from actually clicking on a DOM element:
react-devtools-experimental/src/backend/agent.js
Lines 484 to 490 in eaaeb43
Flare does not work with this, so you can't select a component without also potentially changing it in a significant way. We should find a way to fix this!
cc @trueadm
With Flare, we could provide a prop to that always does preventDefault and stopImmediatePropagation. Would that be a solution?
Seems like it could work, yeah. So long as we could identify when to use the Flare approach vs the normal/synthetic event approach.
Maybe I have got this wrong though. Is this using Flare from within dev tools, or when dev tools interacts with a page using Flare? If the later, then my point above won’t work.
Check out the code snippet I linked to in the bug description.
Essentially, DevTools needs a way to identify that the user has clicked on a DOM element without the event slipping through to the element itself.
We're already using capture:
react-devtools-experimental/src/backend/agent.js
Lines 375 to 378 in eaaeb43
@bvaughn Actually, I just checked. I believe you just need to use pointer events to block Flare; specifically doing stopPropagation()
in pointerdown
and pointerup
as that's where Flare fires most press
events. The ordering is not going to be a problem. Dev tools attaches events to the window
, whilst Flare attaches them to the document
. So any events from window
will always fire first if they're captured.
If you try using
stopImmediatePropagation()
does that fix this issue?
Will check (when I get the chance) and report back.
Thansk!