In the screen I'm using to develop the examples of this chapter, I can see around 15 rows at a time in a Grid component. If I want to see the row 5,390, for example, I have to scroll down and try to find the rows around 5,390. That takes me 1 or 2 seconds if I'm lucky. After this, I have to do some fine-tuned scrolling to get to the exact row. Something that can take 1 or 2 seconds again. This scrolling-through to search data is possible with this example application because the demo data is generated with consecutive numbers for the values in the fields. There are no missing numbers. In other situations, this might not be possible at all. Even in the cases where this is possible, scrolling through thousands of rows is not a good user experience.

Filters aim to help; clicking on a TextField and typing 5,390 is faster than scrolling through the data. However, if the user is supposed to type 5,390, we could argue that rendering thousands of rows is not even required. The whole UI could potentially be redesigned to better fit the use case. When you encounter this kind of Grid with thousands of rows in it, put yourself in others' shoes; in the users' shoes. Consider wizard-like interfaces, infinite lazy loading on scroll (like Facebook or Twitter), or any other event, and splitting the view into several views, each one for a more specific use case.