[docs] Table virtualized

[damianobarbati]

@oliviertassinari would you consider to add a virtual container to the tbody to increase performance when rendering long lists without pagination?
I'll take a stab at this if you could just point me in the right direction (react-virtualized?)

[oliviertassinari]

We hope that the current API allow simple integration with react-virtualized. We are open to do any change to the implementation in order to make the integration simpler.

[oliviertassinari]

Having an demo example in the docs would be awesome.

[oliviertassinari]

If that can help, here is an integration example with the List/Menu https://codesandbox.io/s/oQ0nkl5pk.

[damianobarbati]

@oliviertassinari I made it without react-virtualized because it was a mess and it didn't play nice with mui components.
Furthermore, my current solution is a pure-css fixed thead and scrollable tbody with dynamic table height and dynamic columns width (tested on Safari as well).
The always-on-top thead with a scrollable tbody is a must for data grids.

I'm adding scroll debouncing, tweaking performance and fixing some glitch but it's working great: I'm "virtually" rendering about ~2400rows, sooo smooth.

Questions on Table components:

1. how to use ref with MUI components? I'm auto-computing TableThead height: problem is that

<TableHead ref={ ref => this.tableThead = ref }>

is not returning the actual DOM container element of TableThead but the React instance (native behaviour of React when applying ref on a not-DOM element) because that's something that should be applied in the TableThead component itself; other components may need this, so why not having a refHandler on every MUI component which applies the given callback in the first rendered element? (I hope I managed to explain this out @_@)
My current solution is a weird

const theadHeight = ReactDOM.findDOMNode(this.tableThead).clientHeight; // eslint-disable-line react/no-find-dom-node

which means using the deprecated findDomNode and disabling eslint as well.

2. why is border-bottom applied on cells instead of rows?

3. what about having a stripe={true} prop to automatically stripe TableBody rows?

4. why does .MuiIconButton.root have a zIndex style property? 🤔

I hope to publish something stable about this soon so you can give a look it that's something which can be adopted in a general way.

Sorry to bother this much but I'm heavily using mui@next so I'm spotting a lot of use-cases!

[oliviertassinari]

I made it without react-virtualized because it was a mess and it didn't play nice with mui components.

Oh, that's a shame on us. Any idea what we could do to make is possible?

1. You can try the innerRef to get a ref on the TableHead. ref will get you a ref on the withStyles(TableHead) component. If that doesn't work we could expose a rootRef property. That's a pattern we are already using.

2. No clue

3. What do you mean by stripe?

4. I have removed it in [IconButton] Remove z-index #7467

[damianobarbati]

Oh, that's a shame on us. Any idea what we could do to make is possible?

Actually is a mix of react-virtualized own containers, native table/thead/tbody DOM elements and the need of having a scrollable tbody which caused the problem.
Too much work was needed with it: simply making an ad-hoc solution for MuiTable was a breeze.

1. exposing a rootRef would be great (assuming TableThead main element in the render method is the Thead DOM element itself)

2. should border-bottom be moved to tr then? Should I move this into a dedicated issue?

3. I mean striped rows: easy to achieve with like tr:nth-child(odd) { backgroundColor: f2f2f2 but since we already have the handy hover={true} coloring why not having the an handy striped={true}? :)

4. great!

[oliviertassinari]

1. 👍 Sounds like a plan, here is an example, a PR is welcomed.
2. Bootstrap is doing the same, I think that it's providing more flexibility by using it on the TableCell.
3. Because it's not in the specification and it can be simply implemented on userland?
4. 👍

[damianobarbati]

1. I'm not sure about simply having ref={rootRef} on every component.
   Devs who are using it are probably (mostly) in need to have control over the DOM.
   In your example <FormControl ref={rootRef} ...> will again return a reference to the React component (because FormControl is not a DOM element) and will have the developer use the workaround I had to use.
   Maybe we should have the rootRef behave like the following:

Is the container of the rendered component a DOM element?

• if yes then apply ref={rootRef} on it
• otherwise apply rootRef={rootRef} on it => which is going to propagate down to the first DOM element: this way coder will always have the real DOM reference

The catch-all solution I can think about is having muiRef and rootRef properties where the former applies the callback to the "mui component" container (if any) and the latter applies the callback as I said before.
This way Developer can easily have both/either MUI ref and DOM ref (whatever he needs, whenever he needs).
Do you think this make sense?

2. really? @_@

3. ops! I always forget about the material specs

[oliviertassinari]

1. Oh, I haven't thought about that case. The issue you are referring to is the following:

• Component A takes a ref and a rootRef property
• React intercept ref and apply it on the element
• Component B receive a rootRef property and apply it as a ref on the root Component C
• React intercept this ref and apply it on the element

But what if Component C also have a rootRef property?
Component A can be on user-land, Component B can be the TextField and Component C can be the FormControl.

So my answer, at first we introduced rootRef as a simple helper. We haven't though about industrialization. So, I think that the current behavior is great as deterministic, simple and without the limitation you are describing, if people are interested in accessing the underlying dom element, they can use the findDOMNode API.