React-window: Question: How should we handle native browser find?

[coryhouse]

If someone hits ctrl+f / cmd+f, it will only return results for visible records. Anyone have a suggestion on how to handle this? For now I'm displaying a warning to the user when they hit ctrl+f/cmd+f: "Note that only visible records will be searched with the native browser find. Use the search box provided instead." (I provided a search box above react-window that searches the dataset.)

Any other recommendations?

[TrySound]

In all projects are worked on we built custom filters or search fields near infinite lists.

[bvaughn]

For now, you could override CMD+F and implement custom search using a library like js-worker-search. (I've done this before for apps built with react-virtualized). It won't handle the case where people choose "find in page" from the browser toolbar though.

Google is working on a proposal for this though- (find in page for virtual scrollers). There are a couple of related projects:

• https://github.com/WICG/virtual-scroller
• https://github.com/WICG/display-locking (more recent API proposal here https://github.com/WICG/display-locking/issues/62#issuecomment-516631887)

Basically the proposed API is that content could be rendered in a locked/invisible mode- (so a lot more efficient for the browser) but still be searchable using the native search- then JS would get an "activation" event right before the browser scrolled to the content, so it would have time to tweak it.

Not sure yet how this makes sense for projects like react-window as there would still be a lot of overhead to render everything (in React) or even to fetch all of the data necessary to render it. For now, I think some client search solution will still be important.

I've been chatting with some of the folks at Google about these APIs and doing some experimentation with them. This is a space I'm really interested in :smile:

Going to close this for now btw since it's not really an actionable issue.

[coryhouse]

Excellent, thanks for the thoughtful and quick response @bvaughn! And thanks for all your hard work on this. React-window blew people's mind here in the office. Our customers love it. 👍

[bvaughn]

That's nice to hear. Thank you!

[holic]

In the past, I've solved this by rendering a placeholder for each item/row that contains just the contents of the row but hidden from view (so rendering is super lightweight, effectively a container node and text inside). That way, cmd+f still jumps down the page to ~the right place and the real item/row/cell (and everything around it in the viewport) gets rendered.

I'm not sure if react-window has enough API coverage to do something similar, but I'm planning to play around with this today.

[bvaughn]

I'm not sure if react-window has enough API coverage to do something similar

It doesn't really. Not without kind of abusing/circumventing the API in a way that I'm not sure I would recommend.

[simPod]

@holic did you manage to implement this?

I like the idea of virtualization but the way it breaks cmd+f is confusing to users and leads to misinterpreting the data
(cmd+f AT -> 0 results -> "The AT entry is not in the table, therefore we have not shipped anything to Austria").