When using ag-grid with a cell renderer which has autoHeight=true, the grid renders the rows initially with a set height that looks to be ~40 or 50px, then calculates the height and re-renders the rows with the correct height. I'm wanting to avoid the jump/stutter in the screen caused by the resize and ideally hold off rendering a given row till the height is calculated.
This defect started popping up when upgrading from v25-> v28 of ag-grid.
This Stackblitz Example shows an MVP of this issue. Effectively setting auto height on a cell renderer. To see the issue, you may need to cause the output to refresh (save a code change).
Related
I'm using ag-grid-community v.25.1.0 with 2-rows header and 5 pinned bottom rows.
I want the grid header to be always at fixed position - even when I scroll to the last data rows of my grid (which are often far below the screen bottom).
Unfortunately this forces me to set 'height = 100vh' for the grid - but then the 5 pinned bottom rows also occupy screen area, so there's too small height left for the data rows (about 10 data rows left when I'm using my 13-inch laptop). See demo #1 at https://codesandbox.io/s/aggrid-issue-demo-j9ls9
And if I do not limit grid height with 100vh - then the pinned bottom rows go ouside the screen together with the data rows (because AgGrid's OWN vertical scrollbar is no more shown) which is OK except for... scrolling down the vertical scrollbar of the grid's container (body tag) moves grid's header outside the screen (although "I want header to be always at fixed position" - see this requirement above!). See demo #2 at https://codesandbox.io/s/aggrid-issue-demo-2-52bo3 - it would be OK if header stayed at fixed position.
If there were no pinned bottom rows - the problem would not exist. But these pinned rows are really necessary in my app; however the fact that they occupy ~33% of the grid's height - is a real problem. Yes, I can make row height smaller (together with the font used to paint the cells) - but that's an ugly workaround, not a real solution. I can also provide users with a possibility to show/hide some of the pinned bottom rows (using several checkboxes) - but this "solution" also smells (besides, in most cases all 5 pinned rows are needed).
Is there any solution? maybe I can adjust header's CSS so that it's Y-coordinate stays strictly fixed? in such case removing 'height = 100vh' would solve my problem...
UPD: maybe it makes sense to describe the difference between demos #1 and #2:
App.css:
added this file to override the ".ag-root-wrapper-body.ag-layout-normal" style - because it had height set to zero
App.tsx:
added import for App.css (see above)
removed div style "height: '100vh'"
index.html:
removed body style "overflow-y: hidden;" (to enable vertical scrollbar which is needed to access last rows after we removed '100vh' above)
In ag-grid, the value of domLayout can be set to autoHeight in order to disable vertical scrolling of the ag-grid panel. Instead, the entire page adapts its height to show all the rows.
How can I have the same behavior for the horizontal scrolling?
There is the suppressHorizontalScroll option when set to true hides the horizontal scroll bar, but this doesn't force the entire page to have a scroll. Instead, the overflowing content is just hidden.
you can do this to some extent by juggling the minWidth, maxWidth, and width attributes on your columns while setting the width of the columns automatically based on their content using the gridColumnApi.autoSizeColumns(colId) method.
I say to some extent because it is quite hard, with agGrid, to set different row sizes for rows with certain cells having a lot of text or big images in them. This would force some columns to expand to accommodate for the content, or just clip it completely. Thus forcing the horizontal scroll.
Note : for the method above to work, you need to call gridColumnApi.autoSizeColumns(colId) after you get your rows setUp.
I need to change height of Master/Detail row while expanded i.e. after clicking on some button. I got to the point where I set new height like this.gridOptions.detailRowHeight = 100;. I just don't know how should I refresh grid to display master/detail with changed height. I tried api.resetRowHeights(), but it seems to be only affecting 'parent' rows, not expanded ones (master/detail).
I am scratching my head on this one but I am starting to think it may be a bug in ag-grid.
I have a grid that is (inconsistently) only rendering 3 rows of data when I am expecting 5. There is a blank space for the 2 missing rows.
The pager says 5 rows, and the grid seems to know there are 5 rows (when I step through the javascript debugger). In fact, if I sort on the grid, or resize the window such that the grid provides scrollbars, the other 2 rows suddenly appear.
Has anyone seen anything like this?
----More detail but may not be relevant:
On this particular page, I have 2 grids. There is a main grid that has links in it, and when you click into a link, it hides the main grid and shows you the other grid. I was concerned that that was coming into play somehow, but I actually have seen this on another page I'm working on that has just 1 grid.
Based on various explanations I have seen online, I tried this and it appears to be working:
setTimeout(function ()
{
$scope.gridOptions.api.refreshView();
}, 0);
I call this after
params.successCallback(pResponse.data);
which invokes the grid's callback
Based on your observations that sorting or resizing the window makes the data appear, I get the feeling that the code needs to force the screen refresh somehow.
this.gridOptions.api.refreshView();
I had a similar issue and discovered that my gridOptions.rowHeight value did not match the actual height of my rows (I had a checkbox element in each row that was pushing the height taller).
As it turns out, the AgGrid row renderer uses absolute pixel location to calculate which rows should be visible. So if your actual row heights result in the rows not being in the exact position they are expected to be in, the renderer will skip them.
Ironically, the positioning code uses actual position, so the rows that do get rendered are positioned as if the skipped rows are still there, resulting in the blank space described by the OP.
I have a gtk treeview (inside a GtkScrolledWindow) with two columns.
If I set both columns to the default sizing policy, I have a horizontal scrollbar for the treeview but the columns can't be sized down by the user, which is impractical.
If I set both columns to setSizing Fixed, fixed width 120, I get a nice display and the columns can be resized, but there is no horizontal scrollbar in the treeview (since the columns size down to fit in the width of the treeview I guess).
If I set the first column to setSizing fixed, fixed width 120, the second one to automatic, only the second column is displayed (???).
I would like that by default the first column takes let's say at most 60% of the display, the second column can go all the way and I have a horizontal scrollbar. Certainly I want the user to be able to resize them up or down, not as with the default policy, that you can resize them down!
That's why I tried the first column fixed, the second automatic, it was promessing but I don't understand why the first column is not displayed at all in that configuration.
I add the cell renderers with packstart true, I tried false but it didn't change anything, also I tried setting the expand for the columns to true or false, which didn't have any effect.
Note I'm using the gtk2hs haskell bindings but I'm certain it would be the same in any other gtk binding. Just mentioning if people will ask for code samples.
I'm pretty sure this is a common problem... I'd say nautilus is fixing it the way I'd like to fix it, but I think digging in the nautilus source is going to be quite long...
EDIT well i've discovered the cell renderer's ellipsize setting also has an effect. Setting it to end for the first column and none for the second should be what i want but then the first column is very small and cannot be expanded through resize...
EDIT2 well for now i've moved to word wrapping for the cell renderer, that way i don't have to bother with a horizontal scrollbar... Still curious for the solution to that question though.