Migration to 9.x - ghiscoding/slickgrid-universal GitHub Wiki
Embracing ESM-only builds ⚡ (WIP)
This new release is focused around 2 things, we now ship ESM-only builds (in other words, CommonJS builds are fully dropped and only ESM will remain), this move should help decrease the production build size a little more (at the minimum, npm download size would be cut in half). The other big change is an internal one which is an organizational one, we're moving all framework wrappers directly into Slickgrid-Universal (Angular, Aurelia, React and Vue wrappers are now all located under the frameworks/ folder), this will help tremendously with the project maintenance (any new PR will now run for all frameworks all at once (catching bugs early), publishing a new version is becoming a single click execution for all frameworks all at once, and finally having a single codebase to test & troubleshoot any wrapper, etc... will be just so much easier to handle).
Wait, what happened to version 6 to 8?
I'm skipping versions 6-8 and going straight to v9.0 because some of the wrappers (Angular-Slickgrid, Aurelia-Slickgrid) were already at v8.x and so the next available major version bump for everyone is v9.0
Major Changes - Quick Summary
- minimum requirements bump
- Node v20.0+
- upgrade Vanilla-Calendar-Pro to v3 with flat config
- skipping v6-8 and going straight to v9.0
- now using
clipboard
API, used in ExcelCopyBuffer/ContextMenu/CellCopy, which might requires end user permissions
Note: if you come from an earlier version, please make sure to follow each migrations in their respected order (review previous migration guides)
Changes
Removed @deprecated code
colspanCallback
was deprecated and removed, please use theglobalItemMetadataProvider
instead
gridOptions = {
- colspanCallback: this.renderDifferentColspan.bind(this),
+ dataView: {
+ globalItemMetadataProvider: {
+ getRowMetadata: this.renderDifferentColspan.bind(this)
+ }
+ }
}
- Row Detail changes
itemDetail
property is removed, just useitem
(there's no reason to keep duplicate props)parent
property renamed toparentRef
OnRowBackToViewportRangeArgs
andOnRowOutOfViewportRangeArgs
were equal, so it was merged into a newOnRowBackOrOutOfViewportRangeArgs
interface
export class Component {
notifyTemplate(itemDetail: ItemDetail) {
this.rowDetail.onAsyncResponse.notify(
- { item: itemDetail, itemDetail },
+ { item: itemDetail },
{}, // params
this
);
}
// `parent` renamed as `parentRef`
callParentMethod(model: any) {
- this.parent!.someParentFunction(`We just called Parent Method from the Row Detail Child Component on ${model.title}`);
+ this.parentRef!.someParentFunction(`We just called Parent Method from the Row Detail Child Component on ${model.title}`);
}
}
- Draggable Grouping
setDroppedGroups
to load grid with initial Groups was deprecated and now removed, simply useinitialGroupBy
instead
this.gridOptions = {
enableDraggableGrouping: true,
// frozenColumn: 2,
draggableGrouping: {
- setDroppedGroups: () => ['duration', 'cost'],
+ initialGroupBy: ['duration', 'cost'],
},
};
- for Header Menu, we had 2 similar events
onHeaderMenuHideColumns
andonHideColumns
that were doing basically the same thing, so I decided to droponHeaderMenuHideColumns
- onHeaderMenuHideColumns
+ onHideColumns
Grid Options
rowTopOffsetRenderType
default is changing from 'top'
to 'transform'
and the reason is because transform
is known to have better styling perf, especially on large dataset, and that is also what Ag-Grid uses by default.
previous default | new default |
---|---|
rowTopOffsetRenderType: 'top' |
rowTopOffsetRenderType: 'transform' |
- if you are using Cypress to get the row X in the grid, which is what we do ourselves, then you will need to adjust your tests
Cypress before | Cypress after |
---|---|
cy.get([style="top: ${GRID_ROW_HEIGHT * 0}px;"]) |
cy.get([style="transform: translateY(${GRID_ROW_HEIGHT * 0}px);"]) |
OR cy.get([data-row=0]) |
Please note that you will have to change the default to
rowTopOffsetRenderType: 'top'
when using either RowSpan and/or Row Detail features.
Column Functionalities
Date Editor/Filter
Vanilla-Calendar-Pro was upgraded to v3.0 and the main breaking change is that they migrated to flat config (instead of complex object config) and this mean that if you use any of their option, then you'll have to update them to be flat.
The biggest change that you will most probably have to update is the min/max date setting when using the 'today'
shortcut as shown below:
import { type VanillaCalendarOption } from '@slickgrid-universal/common';
prepareGrid() {
this.columnDefinitions = [{
id: 'finish', field: 'finish', name: 'Finish',
editor: {
model: Editors.date,
- editorOptions: { range: { min: 'today' } } as VanillaCalendarOption,
+ editorOptions: { displayDateMin: 'today' } as VanillaCalendarOption,
}
}];
}
[!NOTE] for a complete list of option changes, visit the Vanilla-Calendar-Pro migration page, which details every single options with their new option names.
Grid Functionalities
Services
The GridService
has CRUD methods that were sometime returning a single item and other times an array of items and for that reason we had to rely on code like onItemAdded.subscribe(item => { const items = Array.isArray(item) ? item : [item] }
. So for that reason, I decided to change the event names to plural and always return an array of items which is a lot more predictable.
onItemAdded
renamed toonItemsAdded
onItemDeleted
renamed toonItemsDeleted
onItemUpdated
renamed toonItemsUpdated
onItemUpserted
renamed toonItemsUpserted
Future Changes
Code being Deprecated (to be removed in the future)
So when I created the project, I used a few TypeScript Enums and I though this was great but it turns out that all of these Enums end up in the final transpiled JS bundle. So in the next major, I'm planning to remove some of these Enums and replace them with string literal types (type
instead of enum
). So you should consider using string types as much and as soon as possible in all your new grids. Note that at the moment, these are only deprecations, and will only be dropped in the future (not now, but you should still consider this for the future), for example:
columns = [{
id: 'age', ...
- type: FieldType.number,
+ type: 'number',
}];
Note that migrating from
FieldType
to string types was already doable for the past couple years, so this one is far from new.