[DevTools Bug]: cannot double click anymore on component name to filter the tree view (in Components tab) (since v6.1.1)

[clementcitiz]

Website or app

None

Repro steps

const A = () => {
  return <div>A</div>;
};

const B = () => {
  return (
    <>
      <div>B</div>
      <C/>
      <D/>
    </>
  );
};

const C = () => {
  return <div>C</div>;
};

const D = () => {
  return <div>D</div>;
};

function App() {
  return (
    <>
      <A />
      <B />
    </>
  );
}

export default App;

1. Open dev tools, Component tab
2. Double click on B: nothing happens

With version 6.0.1, double clicking on B filters the tree by showing only B and its direct children

Tested on Chrome and Firefox with version 6.1.1

How often does this bug happen?

Every time

DevTools package (automated)

No response

DevTools version (automated)

No response

Error message (automated)

No response

Error call stack (automated)

Error component stack (automated)

GitHub query string (automated)

[narekmalk]

Can I take this issue?

[sergiotales1]

Hello!
I tested out here as well and it seems that right now its not possible to filter the tree view, but you can highlight it using the eye on the right side of the console. When you click it will make the tree of the selected component to be slightly highlighted.

Does this help or you need something more specific?

[hmon]

+1
Any news on this?

[clementcitiz]

Hello! I tested out here as well and it seems that right now its not possible to filter the tree view, but you can highlight it using the eye on the right side of the console. When you click it will make the tree of the selected component to be slightly highlighted.

Does this help or you need something more specific?

Hi @sergiotales1 , the eye button does something different and is definitely not the filtering I am used to with double clicking.
Let me clarify:

In this (too simple) example, it looks like the double click only helps seeing the components C and D better. But when on an actual app, for example using Material UI, the double click isolates your components and reduce noise. That's why it's so important to me.

I have to rollback to the previous version of the extension each time it updates to get the filtering back.

Real example:

I double click on LoginTab, then it becomes:

[hoxyq]

Thanks for reporting this, anyone interested in working on a fix for this?

Would be nice to understand first which change caused a regression. The list of changes can be found in changelog.

[clementlize]

Hi @hoxyq, I found the issue. It's been introduced by your commit d85cf3e.

The exact issue happens because you encapsulated all the redux dispatch calls in a transition action (in the function dispatchWrapper).

If I move the dispatch out of the startTransition action, the double click works again.

I found this SO answer explaining that Redux has its own state and that therefore it's not recommended to encapsulate dispatch calls in React transitions. I don't have enough knowledge on the question to know if it's true or why, but it could explain.

I couldn't go deeper on why the transitions system is messing with redux. What I could do is putting logs in the dispatchWrapper function, and also in the reducer. The result is very surprising.

Here is a screenshot of my logs without the transitions system

And here is a screenshot of the same logs with the transitions system

It goes like this for a while (but it's not an infinite loop, it stops at a moment. I'd say we have around 100 logs). I don't know why but it kind of looks like the action is called a lot of times.

Is there any reason you made these changes to use the transitions system there? If the thing has no real value, I could make a PR to rollback and remove the dispatchWrapper function.
You tell me 😃

[hoxyq]

@clementlize, this is a great find.

I found the issue. It's been introduced by your commit d85cf3e.

Just to make sure, have you validated that the double-click action is handled correctly on the parent commit? We've been using this pattern of wrapping dispatcher in a startTransition even before my changes. I've removed startTransition in 717d3ee and brought it back in d85cf3e, but I've probably introduced some side-effects.

Keyboard or click events should not be handled in startTransition, I think this is also the root cause of dropping keystrokes in Components panel search input.

I believe the reason for bringing the startTransition back was the fact that some Suspense boundaries were not resolved in time, more details in #32298.

The exact issue happens because you encapsulated all the redux dispatch calls in a transition action (in the function dispatchWrapper).

The dispatch function is actually used from built-in useReducer hook, so there is no need to dig into internals of redux.

I think this whole approach of dispatch inside startTransition is incorrect. We should probably revert back to the approach before 717d3ee, where we would synchronously dispatch and then start a transition to update inspected view.

[clementlize]

Just to make sure, have you validated that the double-click action is handled correctly on the parent commit?

Yes I tested the parent commit and the double click works

I think this whole approach of dispatch inside startTransition is incorrect. We should probably revert back to the approach before 717d3ee, where we would synchronously dispatch and then start a transition to update inspected view.

Ok, I think I miss some understanding to go on this path. Can I let you try and do something?