Create a widget to query ECSQL strings

[achrysaetos]

On startup:

Bad query:

Successful query:

[aruniverse]

1. the table becomes very slow if the number of results exceeds 5000 rows

You probably want to be using a Virtualized Table

[aruniverse]

what does this actually look like?

[aruniverse]

what is the type for row here when this occurs? i dont think it matches what you had originally typed it as

[achrysaetos]

Looks like this:

When expanded:

[aruniverse]

still feels a little weird for me, have you looked at what the standard pattern we use is?
do we just show as much text as we can before showing an ellipses for overflow, and then on hover show the full text in a tool tip or something?

[achrysaetos]

iModelConsole shows as much as it can in a cell before showing an ellipses for overflow, and then clicking the cell expands the whole row to display the full text. The Table from core doesn't have anything like that, I think, there's just a button to expand the whole row

[achrysaetos]

Or maybe I just have to customize it a bit more.

[aruniverse]

Take a look at what we do for stageId and stageUsage in the other providers in viewer-components-react

[achrysaetos]

1. the table becomes very slow if the number of results exceeds 5000 rows

You probably want to be using a Virtualized Table

Unfortunately, the virtualized table loses the horizontal scrollbar if there are too many columns, and it can't be added back without some (hacky?) css ☹️. Also for some long strings, the virtualized table will only write the visible portion to the DOM, which results in it trying to constantly format each string to fit inside its cell, leading to a jittery experience imo.

The performance gain is very important though...

[aruniverse]

Good work! We'll take it over once you go back to school. Unless you want to continue contributing as an OpenSource Collaborator ;)

[aruniverse]

well wouldnt they always all not be in columnheaders to begin with?
re-read this block of code here

[achrysaetos]

Hmm, I'm pretty sure this is right. I wanted columnHeaders to be the superset of all keys in each row, because sometimes each row might have different keys. So every time columnHeaders encounters a new unique key, it should append the new key. columnHeaders is instantiated before we start iterating through each row.