search

bvaughn / react-devtools-experimental

Experimental rewrite of the React DevTools extension
https://react-devtools-experimental.now.sh
MIT License
965 stars 55 forks source link

Tweak search behavior #301

Closed bvaughn closed 5 years ago

bvaughn commented 5 years ago

Current search behavior is to jump to the first result in the set as you start searching. User feedback has suggested that maybe a better behavior would be to jump to the nearest result (the first one after the selected index) since this would enable matches within the selected tree to be found first.

fanny commented 5 years ago

Nice feature! Looking the search implementation, i saw that it iterate over each node making a dfs. I thought in reordenate the nodes, where who is in the top is the current select node. What do you think about?

bvaughn commented 5 years ago

I though in reordenate the nodes, where who is in the top is the current select node.

I don't know what this means. Can you word it differently?

fanny commented 5 years ago

Of course! I thought in transform the nodes list passed for search in something like a priority queue, in that the first element is the current selected node, and the others are subsequent. This is because, the first results are based on the order of the list. Is this more clear?

bvaughn commented 5 years ago

Let's say we have an app tree in DevTools that looks like what's shown below, and the user has currently selected the "Body" element

▾ App
  ▾ Nav
      Link key="a"
      Link key="b"
  ▾ Body ← currently selected
      Content
  ▾ Footer
      Link key="c"
      Link key="d"

If the user were to search for "Link" there would be four matches, in the order they are specified in the tree.

The current behavior would select Link key="a" first, but this is kind of a bit jarring.

This issue proposes that the first result selected should be the one that comes after the currently selected element. In the above example, that would be Link key="c"

fanny commented 5 years ago

Oh, right. As we have a list, i guess that the list it looks like: [<app>, <nav>, <body>, <footer>]. so, i get the current node selected, and iterate over indexes after it, and since the nodes over, i iterate over the nodes before it. Makes sense?

therefore, the problem technically comes down to determining the index of the current node.

bvaughn commented 5 years ago

I would probably just step through the search results, look at the index of each, and select the first index that's >= the currently selected index.

fanny commented 5 years ago

Sorry, but i'm a little confuse :thinking: , in my understanding, i should select first the results after the current node, but in your answer you say "select the first". So, this implies that nearest result is the first sibling node, that comes after the selected node? And the order of others elements is not important?

Thinking in a real scenario, if i'm in the middle of screen with Body select, probably i'll know the components that comes before, so, i believe that would be nice select first the results after the selected node.

bvaughn commented 5 years ago

in my understanding, i should select first the results after the current node, but in your answer you say "select the first".

My message above said:

and select the first index that's >= the currently selected index.

Isn't this exactly the same thing?

fanny commented 5 years ago

Hmm, I understood that this meant that I should select only the first.

But nice to know we agreed