Next Release Target: TBD - 25.0.0 just released

To work around this issue, you should apply the CSS property display: inline-block; to the parent div (has a class of 'ag-react-container'). This will negate the default "block" display type of the div, so it should show inline with the other elements. This can be seen here: https://next.plnkr.co/edit/lEgeFZy4gE13dFeI

You can implement this behavior using the approach and samples here: https://blog.ag-grid.com/deleting-selected-rows-and-cell-ranges-via-key-press/

Workaround: https://plnkr.co/edit/xngeA6Ixzzr2d9Yq The code is getting the value formatter separately for group rows.

We recommend that you don't define group columns for columns with one column level. Instead, use a custom headerComponent for these one-level columns. In this custom headerComponent element you can arrange layout to span into two lines and center the header text vertically. This way the autosize will take into consideration the first line of the column header too.

Can be workaround with: function isEditable(colId, rowIndex) { return gridOptions.columnApi.getColumn(colId).isCellEditable(rowIndex); }

******* For the time being, we've created a workaround which you can find in the following Plunker which uses a hard-coded refresh: https://next.plnkr.co/edit/peUBAixMVzg3KZfM ******

Until this is implemented, please use this workaround to set tool panel width: https://plnkr.co/edit/X3UHcNrPNfxgkQow

Please implement this functionality in user code following the approach illustrated here: https://blog.ag-grid.com/wrapping-column-header-text/

You can implement row grouping for columns with null/undefined values as follows: https://plnkr.co/edit/rNC5GYdmRLR9Y4LZ

You can implement this when using server-side row model with infinite scrolling using the approach described below. If you have a block size of 200 and want to start loading the next block (with rows 200-400) as soon as the user is scrolling past row index 100, you need to set rowBuffer=100. This way when the user is at row 101, the grid is instantiating row 201, and as that's outside of the data for the current block 0-200, that forces a request for a new block of data (with data for rows 200-400). See this implemented here: https://plnkr.co/edit/55TrdiRAO6y9ViMv?preview I've activated debug: true on ag-grid in this sample, so you can see the messages in the developer console indicating the second block of data is loaded much earlier as the user is scrolling, so the user doesn't see loading indicators unless they scroll really fast. If that's the case, just increase the value of rowBuffer to pre-load more rows to accommodate that.

This is working as expected. When you use a column type, that is selecting default values for the Column Definition. When you provide something then in the cell that is also in the default, the provided overrides the default. So if you are going override the class, make sure the class you provide also aligns text to the left.

This work is now being tracked under AG-3709

This is expected behaviour, when rangeSelections are enabled, clicking on the same cell multiple times will create a new range for each click. If this behaviour is undesired set the gridOptions property: suppressMultiRangeSelection=true. I tried to reproduce in latest and could not. Am assuming it is fixed.

This item was previously released, but not marked as DONE. Now just marking as DONE.

This is not easy to implement. As there is no cell that was clicked on, the grid doesn't know what the column is. This is also not blocking any business functionality - user just needs to right click the cell.

In order for the cell to be refreshed, the grid needs something, either 'field' or 'valueGetter' set on the column, so it can get the value. That is the only way the grid can then tell that the value has changed and the cell needs updating. This is due to the change detection the grid does. To solve, include a valueGetter that will return a different value when the data is loaded. Demonstrated on this plunker: https://plnkr.co/edit/elOLcKx5Y6EnEwHi

This is the workaround, it autosizes cols first before sizing cols to fit: function sizeColsToFit() { // STEP 1: need to autosize cols first to achieve consistent results var allColumnIds = []; gridOptions.columnApi.getAllColumns().forEach(function(column) { allColumnIds.push(column.colId); }); gridOptions.columnApi.autoSizeColumns(allColumnIds); // STEP 2: then size cols to fit gridOptions.api.sizeColumnsToFit(); } https://plnkr.co/edit/02RGrvx6f0VESIQJqPKz?p=preview Note the reason for this inconsistent behaviour is due to the algorithm uses a ratio of widths and takes the actualWidths into account, but these are successively changing. The workaround ensure that each time we call sizeColumnsToFit() the actualWidths will be the same each time.

This functionality is currently impossible due to browser security restrictions on clipboard access. Please read additional details here: https://www.ag-grid.com/javascript-grid-clipboard/#paste-from-clipboard

We have created the following example: https://next.plnkr.co/edit/tRskkv08jyOLmmv9?preview Note that this is pretty much like a custom rewrite of the aligned grids to suit your needs.

There is a workaround in our knowledge base: https://ag-grid.zendesk.com/hc/en-us/articles/360020374692

This feature request is declined because it isn't a reasonable requirement. It's not the responsibility of the filter to test whether the condition that would produce no rows. If a user selects filter range (value > 20 && value < 10) that's a valid boolean condition, that all the filter is concerned with. Excel behaves the same way - it allows the user enter the same filtering condition (value < 10 && value > 20) and returns 0 rows without any errors/warnings.

I tried to reproduce this but couldn't. The plunker provided by the customer is no longer working. I found the description of what was going on unclear. If this is still an issue, customer can get in touch and support should provide a clearly reproducible scenario for the dev team.

Workaround in our KB https://ag-grid.zendesk.com/hc/en-us/articles/360020323071-Adding-cut-support

We are adding a side button to the grid, we are hoping to shortly add the ability to add more side panels/hide already shown, we think this should will cover the same functionality but it will be more flexible.
Check the documentation for tool panel. Tool panel has been revamped and changed considerably from v16