-
Notifications
You must be signed in to change notification settings - Fork 10
AG Grid upgrade to v34 #4062
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
AG Grid upgrade to v34 #4062
Conversation
New Sizes for ag-Grid, zipped: Prev sizes for ag-Grid, zipped. (react included in community) @amcclain -- need to discuss -Lee
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome that we are off to the races on this. I took a first pass just now - need to break for a bit but will return to this testing more intensively with one or two selected apps.
// had ever been specified, `undefined` must be used. | ||
col.setSort(undefined, null); | ||
col.setSortIndex(undefined); | ||
agApi.applyColumnState({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the comment at the top of this conditional block is outdated and should be removed, is that correct? "ag-Grid does not allow "secondary" columns to be manipulated by applyColumnState..."
Now that we are able to use applyColumnState
for both operations, should we be collecting all the changes - both for the singular AUTO_GROUP_COL_ID
and any of these getPivotResultColumns()
into one array of changes applied via single call to applyColumnState
?
ValueSetterParams | ||
ValueSetterParams, | ||
CustomCellEditorProps, | ||
CellClickedEvent | ||
} from '@xh/hoist/kit/ag-grid'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Big 👍 on this change
@@ -294,7 +295,7 @@ function levelExpandAction(gridModel: GridModel): RecordAction { | |||
return { | |||
icon: isCurrLevel ? Icon.check() : null, | |||
text: label, | |||
actionFn: () => gridModel.expandToLevel(idx) | |||
actionFn: () => wait().then(() => gridModel.expandToLevel(idx)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a change we might make directly on current develop
? I didn't test it out myself but I am guessing this gives us better menu dismiss behavior without a potential wait?
I'm always in favor of explicitly commenting waits and debounces so it's clear why we're doing them - otherwise they can be mysterious. Happy to add that assuming I'm correct about the reason behind the change.
enableClickSelection: selModel.isEnabled, | ||
isRowSelectable: () => selModel.isEnabled, | ||
checkboxes: false, | ||
headerCheckbox: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need to grow the scope of this upgrade - good arguments to be made for avoiding that! - but I'm struck that supporting checkboxes for selection is something that comes up from time-to-time and that we have a dedicated toolbox example around it. If we could pull through an option to use the built-in that might be a really nice win.
We could file as a follow-on ticket.
{contextMenu} = model; | ||
if (!contextMenu || XH.isMobileApp || model.isEditing) return null; | ||
|
||
// Manipulate selection if needed. | ||
if (!agOptions.suppressRowClickSelection) { | ||
if (model.selModel.isEnabled) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a good change here, although makes me wonder why we were using the agOption
before... 🤔 Do you suppose there was any chance we wanted/needed to ensure we respected the direct use of the option?
cmp/grid/GridModel.ts
Outdated
@@ -1562,7 +1563,7 @@ export class GridModel extends HoistModel { | |||
if (empty) { | |||
agApi.showNoRowsOverlay(); | |||
} else { | |||
agApi.hideOverlay(); | |||
agApi.updateGridOptions({loading: false}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticed the asymmetry here where we don't unset loading
in the empty case and clicked through to agApi.showNoRowsOverlay()
impl - that method has a doc comment saying it will have no effect if loading. Tested and confirmed that the load mask does not re-appear - will see if I can adjust
|
||
const portalContainer = props.gridModel.viewRef.current?.querySelector( | ||
'.ag-body-viewport' | ||
) as HTMLElement; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth making a getter on gridModel
to encapsulate the selector and all that?
- `showNoRowsOverlay` documented as a no-op if `loading: true`
agApi.hideOverlay(); | ||
} | ||
agApi.updateGridOptions({loading: false}); | ||
if (empty) agApi.showNoRowsOverlay(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made a change here but then tested a bit more and am not sure that we even need the call to showNoRowsOverlay
- commenting it out, filtering a grid to no rows, then autosizing - I still see the overlay. Might be able to remove but didn't want to be overly hasty
Hoist P/R Checklist
Still pending a bit more testing, especially mobile, and also the tricky handling of pivot grid state in raw ag-Grid which had to change. (the latter is commented as being unreliable currently fwiw)
There is a branch
agUpgrade
that just has the changes to v32, but I don't think we are likely to use that -- we might as well go all the way to the current version, unless there is some unexpected problem with the new packaging.Pull request authors: Review and check off the below. Items that do not apply can also be
checked off to indicate they have been considered. If unclear if a step is relevant, please leave
unchecked and note in comments.
develop
branch as of last change.breaking-change
label + CHANGELOG if so.If your change is still a WIP, please use the "Create draft pull request" option in the split
button below to indicate it is not ready yet for a final review.