Internal grid rendering uses different height than overall outline

[Dev63]

When using flex-grow to ensure that the grid takes 100% of the height available, it correctly shows its outline, but then draws its internals as if the height available had been calculated with every hidden div on the page actually shown. The result is that the footer gets drawn in the middle of the table, raised by the vertical amount of any hidden div.

If you resize the window, everything then draws correctly. It's just the initial setup that is incorrect. Unfortunately, calling gridApi.handleWindowResize() or gridApi.refresh() does nothing, probably because it detects that the window hasn't actually changed size.

Here's a plunker showing these flex-grow problems with ui-grid. It uses a slightly modified form of the code from ui-grid tutorial 101. By clicking the "Toggle Hidden" button, you can see that when the hidden div is shown, the table draws properly. Well, it would, except someone just published on the unstable branch a problem with the bottom scrollbar getting drawn a bit too high, but I assume that will be resolved shortly.

I could imagine that it might be tricky to fix this, but sure would appreciate a workaround, or even a call that would actually force the grid to redraw.

[PaulL1]

We have some outstanding questions and documentation that we need to do around the various refresh and redraw methods, and which of them do what. Refer #1818

[Dev63]

@PaulL1 that would be great if there's some method that can be called to force the table to recalculate its parameters. As I show above, the table outline itself gets it right, but then the internals don't. I've tried every call I could find documented, but nothing fixes it. Of course, even better would be a fix to this behavior!

[Dev63]

Turns out that calling gridApi.core.handleWindowResize will "solve" the initial appearance. However, if the hidden div above the table then later becomes visible, the table contents get displaced down by that amount, but the table outline has some issues (doesn't draw the side lines for the newly extended bottom ... and the workaround for footer is overlapped by scrollbar causes the scrollbar not to displace (gah!)).

[PaulL1]

handleWindowResize is a subset of redraw, the other option is gridApi.core.refresh(), which should do a more complete redraw. That might meet your needs as well.

[Dev63]

Thanks, Paul.

Further investigation reveals that the root of this problem lies in placing the grid in a flex-grow:1 div (which I would think would be reasonably common). Using ui-grid-auto-resize resolves the drawing problems, although there is some ugly redrawing. It's too bad that ui-grid-auto-resize is necessary, given its performance impact, but at least there's a clear resolution.

FWIW, it seems that you almost don't need it. If someone ever wants to deal with this, here are some clues:

1. The initial grid content draws itself leaving enough space inside the bottom of its table outline to accommodate the hidden div earlier on the page (as shown above). This may be related to the timing of when a flex-grow is calculated.
2. Resizing the window or calling handleWindowResize will fix things. But when the hidden div later materializes above the grid, the overall grid resizes and shifts correctly, but the grid content only shifts and does not resize, resulting in the content breaking out of the grid, actually displaying under whatever else is there).
3. In turn, this causes the addition of a vertical scrollbar since the page is now incorrectly >100%. The addition of the vertical scroll bar "freaks out" the grid, which now keeps the row selectors in place but draws all the rest of the content below the original placement of the table, since it no longer fits (given the presence of the scrollbar).

Leaving enough blank space below the table to accommodate the materialization of the hidden div avoids the introduction of the scrollbar, and the table remains OK (other than breaking out of the bottom). But of course, this is not always practical or an efficient use of space.

Anyhow, I hope this is helpful, and I can either choose to take the performance and redrawing ugliness of ui-grid-auto-resize, or skip the hidden divs.

[McShazy]

Thinking out-loud: ui-grid-auto-resize seems like more of a hack to me in it's current implementation. If we have five grids on the page, does that mean we have five different timeouts/intervals? This could severely have a performance impact, no? Are there plans in the make for a more elegant solution?

[PaulL1]

This is a useful request, but not really in the current roadmap. We have far too many good ideas in the repository already, giving the impression that we have a project riven with defects.

Accordingly, I am leaving the enhancement tag on this, but closing it. If someone would like this functionality, we'd welcome a pull request that adds it.