Skip to content

Fix search element selection #30

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tsriram wants to merge 2 commits into from
Closed

Fix search element selection #30

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
25eb5ea
fix search element selection
tsriram Mar 9, 2019
790f680
update condition to set selected element
tsriram Apr 1, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions src/devtools/views/Elements/TreeContext.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -195,9 +195,11 @@ function reduceSearchState(store: Store, state: State, action: Action): State {
} = state;

const prevSearchIndex = searchIndex;
console.log('searchIndex: ', searchIndex);
const numPrevSearchResults = searchResults.length;

// Search isn't supported when the owner's tree is active.
console.log('type: ', type);
if (ownerStack.length === 0) {
switch (type) {
case 'GO_TO_NEXT_SEARCH_RESULT':
Expand Down Expand Up @@ -288,7 +290,6 @@ function reduceSearchState(store: Store, state: State, action: Action): State {
store.roots.forEach(rootID => {
recursivelySearchTree(store, rootID, regExp, searchResults);
});

if (searchResults.length > 0) {
if (prevSearchIndex === null) {
searchIndex = 0;
Expand All @@ -308,7 +309,7 @@ function reduceSearchState(store: Store, state: State, action: Action): State {
}

// Changes in search index should override the selected element.
if (searchIndex !== prevSearchIndex) {
Copy link
Owner

@bvaughn bvaughn Mar 26, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea behind this was to avoid having to pay the cost of getIndexOfElementID every time the context re-rendered. That lookup isn't too expensive but it's also something I'd like to avoid doing unnecessarily. In theory, if the index didn't change, we shouldn't need to look things up again.

I wonder if we could treat 0 as a special case...

Ideally we could just detect the case where we need to re-run the computation for index 0, and reset prevSearchIndex to e.g. null at the start of the reducer.

Copy link
Owner

@bvaughn bvaughn Mar 26, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you come up with a small repro steps by chance? 😄 I forget what sequence used to trigger this.

Copy link
Contributor Author

@tsriram tsriram Apr 1, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we could handle index 0 as a special case and updating the original if condition with an additional check for index 0 makes it work. Does this make sense?

Reproduction is quite easy (if I understand it correctly 😉):

  1. Go to https://react-devtools-experimental.now.sh/
  2. In the devtools search box, type list - first element <List> should be selected
  3. Continue typing and enter listitem - ideally the second element in the tree <Memo(ListItem)> should be selected but the first element is still shown as selected.

react-devtools-repro

You could see another example in my original screen grabs as well in the PR.

if (searchIndex !== prevSearchIndex || prevSearchIndex === 0) {
if (searchIndex === null) {
selectedElementIndex = null;
selectedElementID = null;
Expand Down