angular-slickgrid 9.0.0 → 9.0.2

package/docs/migrations/migration-to-7.x.md

@@ -1,294 +0,0 @@
-## Merging SlickGrid into `Slickgrid-Universal` (dropping `6pac/slickgrid` dep)
-### The aim of this release is to be standalone, improve best practices & move towards CSP compliance while also making the project leaner.
-
-There are a few changes, but it's for good reasons 😉
-
-This new major release is dropping SlickGrid dependency (`6pac/slickgrid`) dependency entirely and no longer relies on external SlickGrid code. All core files are now included into the Slickgrid-Universal project instead of being an external dependency which was sometime hard to troubleshoot (which was the case for the past couple years). The main reason to move the core lib into the Slickgrid-Universal project is for simplicity but it also allows us to drop code that we never really used in Slickgrid-Universal (e.g. SlickGrid had its own `autosize` which is different than our implementation in `ResizerService`, see Slickgrid-Universal [Example 31](https://ghiscoding.github.io/Angular-Slickgrid/#/resize-by-content)). Migrating SlickGrid to native JS (dropping jQuery) also required a few DOM utils that were duplicated in both projects, with this release we can now deduplicate these methods. It was hard or impossible to achieve earlier because SlickGrid was always written as a JavaScript library while our project was written in TypeScript, but now that SlickGrid core lib was also migrated to TypeScript (I'm actually the person who worked on that), this is now allowing me to simply copy the new TypeScript code and merge it in here without too much effort. It's also been tested in the wild for couple months already and all bugs were discovered and fixed already, so I know the new code is also stable already.
-
-Another great feature of this new major release is that I made a lot of improvements on the library for CSP (Content Security Policy) compliance, or at least provide ways to be compliant. One of the biggest change in that regard is that you can now create custom Formatters to return native HTML element (I rewrote a few built-in Formatters with that approach) and this is mostly to avoid the use of `innerHTML` which is not CSP safe by default.
-
-With this new major version release, we can now say that the journey to modernize the project is now, for the most part, completed (in summary the following was achieved in Slickgrid-Universal: 1. dropped jQueryUI in v2, dropped jQuery v3 and now in v4 Slickgrid-Universal is no longer relying on external 6pac/SlickGrid dependency and is fully written in TypeScript with full ESM builds) and with that said, I do not expect any major changes (aka breaking) for the foreseeable future... we're pretty much done with the big changes!!! This new release should be a little more performant too with more native code, e.g. some Formatters were rewritten as native.
-
-#### Major Changes - Quick Summary
-- minimum requirements bump
-  - Node 18 is now required
-  - Slickgrid-Universal >= 4.x is now required
-  - TypeScript builds are now targeting ES2021 (bumped from ES2018)
-  - more CSP (Content Security Policy) safe
-  - you can create custom Formatter with native HTML element (to be more CSP safe), HTML strings are still accepted
-  - migrate to [Excel-Builder-Vanilla](https://github.com/ghiscoding/excel-builder-vanilla) (since >=4.4.0)
-    - for CSP safe, you also need to add `worker-src 'self' blob:;`
-
-> **Note** for the full internal list of code changes applied in this Slickgrid-Universal release, you can take a look at the [Discussion - Roadmap to 4.0](https://github.com/ghiscoding/slickgrid-universal/discussions/1108)
-
----
-
-**NOTE:** if you come from an earlier version, please make sure to follow each migration in their respected order (see Wiki index)
-
-> **Note** after following the migration, if you have some build errors with missing `slickgrid` that is because you did not upgrade all Slickgrid-Universal dependencies that you may have. So in short **do not install SlickGrid** manually, this is wrong and we are no longer depending on 6pac/slickgrid since Slickgrid-Universal now has its own SlickGrid/SlickDataView core files.
-
-## Changes
-
-### Slickgrid-Universal
-If you use any of the Slickgrid-Universal extra dependencies then make sure to upgrade them as well to the new major `4.0.0` version so that they work with Angular-Slickgrid `7.0.0`
-
-```diff
-  "dependencies": {
--   "@slickgrid-universal/excel-export": "^3.7.1",
-+   "@slickgrid-universal/excel-export": "^4.0.1",
--   "angular-slickgrid": "^6.6.0",
-+   "angular-slickgrid": "^7.0.0",
-}
-```
-
-### `angular.json` config
-Since we moved all the code into the Slickgrid-Universal project and it is now written in TypeScript, we can now say for certain that SlickGrid is no longer detected as CommonJS, we also no longer need SortableJS to be preloaded. So you can do the following changes to your `angular.json` config
-
-```diff
-# angular.json
-{
-  "allowedCommonJsDependencies": [
-    "autocompleter",
-    "dompurify",
--   "excel-builder-webpacker",
-    "flatpickr",
--   "slickgrid",
-    "stream"
-  ],
-  // ...
-  "scripts": [
-    "node_modules/bootstrap/dist/js/bootstrap.min.js",
--    "node_modules/sortablejs/Sortable.min.js"
-  ],
-  // ...
-}
-```
-
-### Distribution folder
-The `dist/commonjs` folder was renamed as `dist/cjs` to make it shorter and also to follow the new convention used in the JS world.
-- this should be transparent for most users
-
-#### `Slick` namespace on the `window` object is gone
-By migrating the SlickGrid core files into the project, we are now taking full advantage of TypeScript classes but that is also indirectly drops the `Slick` namespace on the `window` object. The main usage of the `Slick` namespace for most users, is when you have an editable grid with the "undo" functionality, you will need to update your code as shown below.
-
-```diff
-+ { SlickEventHandler, SlickGlobalEditorLock }  from '@slickgrid-universal/common';
-- declare const Slick: SlickNamespace;
-
-// ..
-- eventHandler = Slick.EventHandler();
-+ eventHandler = SlickEventHandler();
-
-// ..
-undo() {
-    const command = this.editCommandQueue.pop();
--    if (command && Slick.GlobalEditorLock.cancelCurrentEdit()) {
-+    if (command && SlickGlobalEditorLock.cancelCurrentEdit()) {
-      command.undo();
-    }
-}
-```
-
-### Composite Editor
-The `CompositeEditor` class got renamed to `SlickCompositeEditor`, so if you were using it with an `instanceof` then you will have to update your code.
-```diff
-- if (args.editor instanceof Slick.CompositeEditor) {
-+ if (args.editor instanceof SlickCompositeEditor) {
-  // ...
-}
-```
-
-### Deprecated code removed/renamed
-##### Column
-- `exportColumnWidth` was removed, just use `excelExportOptions` instead
-
-##### Grid Options
-- `defaultComponentEventPrefix` - no longer available
-- `defaultSlickgridEventPrefix` - no longer available
-- `sanitizeHtmlOptions` was renamed to `sanitizerOptions` (can be useful to provide extra sanitizer options like DOMPurify)
-- `registerExternalResources` was renamed to `externalResources`
-
-```diff
-this.gridOptions = {
-- registerExternalResources: [new ExcelExportService()]
-+ externalResources: [new ExcelExportService()]
-}
-```
-
-##### GraphQL Service
-- `isWithCursor` was renamed to `useCursor`
-
-##### Header Menu
-- `items` list was renamed as `commandItems` to align with all other Menu extensions
-
-##### Filter/Editor
-Any Editor/Filter options (internal or 3rd party lib like Flatpickr, Autocompleter, ...) were migrated from `params` to `filterOptions` or `editorOptions`. You can still use `params` for other usage though.
-```diff
-this.columnDefinitions = {
-{
-  id: 'duration', name: 'Duration', field: 'duration',
-  filterable: true,
-  filter: {
-    model: Filters.slider,
--   params: { hideSliderNumber: true } as SliderOption
-+   filterOptions: { hideSliderNumber: true } as SliderOption
-  },
-  editor: {
-    model: Editors.slider,
--   params: { hideSliderNumber: true } as SliderOption
-+   editorOptions: { hideSliderNumber: true } as SliderOption
-  },
-}
-```
-
-### Package Location Change
-_This should be transparent and irrelevant to most users..._
-
-- `BindingEventService` moved from `@slickgrid-universal/common` to `@slickgrid-universal/binding`, you will also need to check your dependencies and apply changes if you have it installed.
-```diff
-- import { BindingEventService } from '@slickgrid-universal/common';
-+ import { BindingEventService } from '@slickgrid-universal/binding';
-```
-
-### Removed functions
-_This should be transparent and irrelevant to most users..._
-- remove leftover jQuery slide/fade animations in all toggle methods, use CSS animation instead. We are removing the last `animate` boolean argument that was previously available on all of these methods:
-  - `setTopPanelVisibility`, `setHeaderRowVisibility`, `setColumnHeaderVisibility`, `setFooterRowVisibility`, `setPreHeaderPanelVisibility`
-
-### Rename Util functions (shorter names)
-_This should be transparent and irrelevant to most users..._
-
-Some of the DomUtils Service function were renamed, if you use any of them then rename them (the first 2 are used in multiple places)
-- `getHtmlElementOffset` renamed to `getOffset`
-- `sanitizeHtmlToText` reimplemented as `stripTags`
-- `destroyObjectDomElementProps` renamed to `destroyAllElementProps`
-- `getElementOffsetRelativeToParent` renamed to `getOffsetRelativeToParent`
-- `findFirstElementAttribute` renamed to `findFirstAttribute`
-- `htmlEncodedStringWithPadding` renamed to `htmlEncodeWithPadding`
-
-### Excel Export
-_requires version >=7.4.0_
-
-Migrate to a new [Excel-Builder-Vanilla](https://github.com/ghiscoding/excel-builder-vanilla) which is a fork of the `excel-builder.js` library. The new fork is all about modernizing Excel-Builder, it drops `Q`, `Lodash` and also replace `JSZip` to `fflate`.
-
-By migrating from `JSZip` to `fflate`, the users should remove any `JSZip` references (like `tsconfig.json`)
-
-```diff
-{
-  "compilerOptions": {
--    "paths": {
--      "jszip": [
--        "node_modules/jszip/dist/jszip.min.js"
--      ]
--    }
-  }
-}
-```
-
-Also note that `fflate` could use Web Worker for performance reasons and by doing this you might have new CSP errors thrown. You simply need to add a CSP rule to avoid the error `worker-src 'self' blob:;`
-
-## Formatters / CSP (Content Security Policy) Compliance
-### Formatters Cleanup & Removals
-I decided to remove a bunch of Formatters (like `Formatters.bold`, `Formatters.uppercase`, ...) because they could and should be using the column `cssClass` option. Basically, I did not myself use the best practice available when creating soo many Formatters and I did not realized that we could simply use `cssClass` which is a much more efficient way and so I'm correcting this inadvertence in this new release. With that in mind, I decided to do a big cleanup in the list of Formatters to make the project a little more lightweight with less code to support and replace some of them with more generic alternatives (see below).
-
-The benefits of using `cssClass` are non negligible since it will slightly decrease the project size and code to support, but most importantly it is a lot more efficient, because applying CSS is a lot quicker in comparison to parse and apply a formatter on each cell. See below for the list of deleted (or replaced) Formatters and their equivalent Column `cssClass` property to use (when available).
-
-> **Note** the CSS class name to use might be different depending on which framework you use in your project, i.e. Bootstrap/Bulma/Material
-
-```diff
-this.columnDefinitions = [
-  {
-    id: 'firstName', name: 'First Name', field: 'firstName',
--   formatter: Formatters.bold
-+   cssClass: 'text-bold'
-  },
-  {
-    id: 'lastName', name: 'Last Name', field: 'lastName',
--   formatter: Formatters.multiple, params: { formatters: [Formatters.uppercase, Formatters.bold] },
-+   cssClass: 'text-uppercase text-bold'
-  },
-  {
-    id: 'deleteIcon', name: '', field: '',
--   formatter: Formatters.deleteIcon,
-    // NOTE: we previously accepted "icon" and "formatterIcon" in the past but these names are now removed
-+   formatter: Formatters.icon, params: { iconCssClass: 'fa fa-trash pointer' }
-  },
-];
-```
-| Formatter removed | `cssClass` equivalent | alternative |
-| ------------------|-----------------------|------------------------|
-| `Formatters.bold` | `cssClass: 'text-bold'` or `fw-bold` |
-| `Formatters.center` | `cssClass: 'text-center'` |
-| `Formatters.italic` | `cssClass: 'text-italic'` or `fst-italic` |
-| `Formatters.alignRight` | `cssClass: 'text-right'` or `text-end` |
-| `Formatters.lowercase` | `cssClass: 'text-lowercase'`|
-| `Formatters.uppercase` | `cssClass: 'text-uppercase'`|
-| `Formatters.fakeHyperlink` | `cssClass: 'text-underline cursor'` | `cssClass: 'fake-hyperlink'` |
-| `Formatters.checkbox` | n/a ... removed | use the `Formatters.iconBoolean` |
-| `Formatters.deleteIcon` | n/a ... removed | use the `Formatters.icon` (see above) |
-| `Formatters.editIcon` | n/a ... removed | use the `Formatters.icon` (see above) |
-| `Formatters.infoIcon` | n/a ... removed | use the `Formatters.icon` (see above) |
-| `Formatters.yesNo` | n/a ... rarely used, so it was removed |  create a custom Formatter |
-
-### All Formatters were rewritten as native HTML (CSP Safe)
-The previous Formatters implementation were all returning HTML strings (or `FormatterResultObject`), however that approach was not CSP safe by default and we have to do some extra transformations in order to be CSP safe. The transformation is to take the HTML string, sanitize it (DOMPurify is used by default unless a custom `sanitizer` is provided, for example in Salesforce DOMPurify doesn't work so a custom sanitizer is provided) and if you do use DOMPurify then its transformation will return `TrustedHTML` (when enabled with `RETURN_TRUSTED_TYPE: true` which is the default in here) which is CSP safe and we can finally assign it the cell content via `innerHTML` but as you can see, that required couple of extra steps. With that in mind, if we were to return native HTML directly from our Formatter, we could then bypass any transformations and simply use `.appendChild()` and that is exactly why I decided to rewrite some built-in Formatters as native code, the bonus is that this is much more efficient (no transformation) and is also 100% CSP safe since it's already native. For the most part this change shouldn't affect you too much **unless** you chained some of these Formatters (e.g. with `Formatters.multiple`) or if you were expecting an HTML string that you were then concatenating another string to a built-in Formatter result, then that might break your UI and you will have to update your code.
-
-> **Note** prior to this release, Slickgrid-Universal only supported returning HTML string (or via an object of type `FormatterResultObject`). With this release, we still support returning HTML string but now we also support returning native HTML in addition (or as `FormatterResultWithHtml`)
-
-**Since all Formatters were rewritten as HTML, you might get unexpected behavior in your UI, you will have to inspect your UI and make changes accordingly**. For example, I had to adjust [Example 30](https://ghiscoding.github.io/Angular-Slickgrid/#/composite-editor) `customEditableInputFormatter` because it was expecting all Formatters to return an HTML string and I was concatenating them to an HTML string but that code was now resulting in `[object HTMLElement]`, so I had to update the code and detect if Formatter output is a native element then do something or else do something else... Below is the adjustment I had to do to fix my own demo (your use case may vary)
-
-> **Note** some Formatters now return `HTMLElement` or `DocumentFragment`, you can add a condition check with `instanceof HTMLElement` or `instanceof DocumentFragment`, however please also note that a `DocumentFragment` does not have `innerHTML`/`outerHTML` (you can write a simple function for loop to get them, see this [SO](https://stackoverflow.com/a/51017093/1212166) or use `getHTMLFromFragment(elm)` from Slickgrid-Universal)
-
-```diff
-const customEditableInputFormatter: Formatter = (_row, _cell, value, columnDef, dataContext, grid) => {
-  const isEditableLine = checkItemIsEditable(dataContext, columnDef, grid);
-  value = (value === null || value === undefined) ? '' : value;
--  return isEditableLine ? `<div class="editing-field">${value}</div>` : value;
-+  const divElm = document.createElement('div');
-+  divElm.className = 'editing-field';
-+  if (value instanceof HTMLElement) {
-+    divElm.appendChild(value);
-+  } else {
-+    divElm.textContent = value;
-+  }
-};
-
-init() {
-  // ...
-  this.gridOptions = {
-    editable: true,
-    autoAddCustomEditorFormatter: customEditableInputFormatter,
-  }
-}
-```
-here's also another use case from [Example 18](https://ghiscoding.github.io/slickgrid-universal/#/example18) using a `DocumentFragment`
-```diff
-const priceFormatter: Formatter = (_cell, _row, value, _col, dataContext) => {
-  const direction = dataContext.priceChange >= 0 ? 'up' : 'down';
--  return `<span class="mdi mdi-arrow-${direction} color-${direction === 'up' ? 'success' : 'danger'}"></span> ${value}`;
-+  const fragment = document.createDocumentFragment();
-+  const spanElm = document.createElement('span');
-+  spanElm.className = `mdi mdi-arrow-${direction} color-${direction === 'up' ? 'success' : 'danger'}`;
-+  fragment.appendChild(spanElm);
-+  if (value instanceof HTMLElement) {
-+    fragment.appendChild(value);
-+  }
-+  return fragment;
-};
-
-init() {
- this.columnDefinitions = [
-   {
-      id: 'priceChange', name: 'Change', field: 'priceChange', filterable: true, sortable: true, minWidth: 80, width: 80,
-      filter: { model: Filters.compoundInputNumber }, type: FieldType.number,
-      formatter: Formatters.multiple,
-      params: {
-        formatters: [Formatters.dollarColored, priceFormatter],
-        maxDecimal: 2,
-      }
-    },
-  },
-];
-```
-
-> **Note** you might be wondering, why do we use a `DocumentFragment` and not just `HTMLElement`? The reason is simply because in some cases you might just want to return multiple elements but without having to wrap them inside a div container... and so you probably guessed it that a `DocumentFragment` allows you to do just that. However please note that it might not be supported by all environment (e.g. Salesforce doesn't support it yet), so a grid option `preventDocumentFragmentUsage` flag was provided and it will instead wrap the elements inside a `span` instead of the fragment (e.g. Tree Formatter uses this technique).

package/docs/migrations/migration-to-8.x.md

@@ -1,316 +0,0 @@
-## Version 8 - Better UI and Dark Mode with Pure CSS SVG icons ✨
-This new release brings a lot of changes oriented towards better UI/UX, our SVG icons are now pure CSS and can be colorized like any other text via the native CSS `color` property (which helps a lot to improve the Dark Mode Theme).
-
-Another noticeable UI change is the migration from [Flatpickr](https://flatpickr.js.org/) to [Vanilla-Calendar-Pro](https://vanilla-calendar.pro/), there are multiple reasons to migrate our date picker to another library as described below. Another change that is mostly internal but is also indirectly connected to the date picker is the migration from MomentJS to [Tempo](https://tempo.formkit.com/) which is modern and is packaged as ESM which is great for Tree Shaking.
-
-##### Flatpickr cons:
-  - barely supported (lots of opened PRs but nothing merged for the past 2 years)
-  - not fully ESM ready (it's only partially ESM, for example it was detected as CJS in Angular-Slickgrid and required an exception in `allowedCommonJsDependencies`)
-  - styling could be a bit more modern (the use of native select/input to change year/month/time is a little outdated)
-  - date range selection is not very user friendly (UX)
-
-##### Vanilla-Calendar (VC)
-  - pros:
-    - ESM ready
-    - modern styling and also includes Dark Mode theme
-    - date range selection is a lot easier by displaying 2 months at a time in the picker
-  - cons:
-    - build size is slightly larger but its UI/UX is just awesome (especially when changing month/year)
-    - settings are a bit different and are not using flat config (complex object settings) and requires code change
-      - for example Flatpickr `minDate: 'today'` becomes `range: { min: 'today' }` in VC
-    - some settings were missing, like the `'today'` shortcut, so I also contributed back to that project.
-
-To summarize, the goal of this new release was mainly to improve UI/UX (mostly for Dark Mode) and also to make it fully ESM ready. Also noteworthy, the project is smaller in size (~100Kb smaller) compared to what it was in v2.x (that was when the user had to install jQuery/jQueryUI separately). So, considering that we're no longer requiring the install of jQuery/jQueryUI, and also considering that these 2 dependencies had a total of well over 200kb. We can safely assume that our project build size is in fact a lot smaller than it was 2 years ago, that is really nice to know considering that we kept adding features (like Dark Mode and other features) while still decreasing its size over the years :)
-
-With this release, and after 7 years of development as a single developer (myself @ghiscoding), I believe that I have achieved all goals and even more than I originally planned. So with that being said, I am not foreseeing any new major releases for a while. As a recap, I think that the biggest challenge was the removal of jQuery/jQueryUI and transitioning to native code, that took 2-3 years to accomplish which I am of course very proud to have achieved. All dependencies are now also all ESM and the project is now CSP compliant as well. If the project is useful to you, give it a ⭐ and perhaps buy me a [☕ (ko-fi)](https://ko-fi.com/ghiscoding), thanks.
-
-#### Major Changes - Quick Summary
-- minimum requirements bump
-  - Angular v18.0+
-  - Node v18.0+
-  - Bootstrap v5.0+ (or any other UI framework)
-  - SASS v1.35+ (`dart-sass`)
-  - migrated from Flatpickr to Vanilla-Calendar-Pro (visit [Vanilla-Calendar-Pro](https://vanilla-calendar.pro/) for demos and docs)
-  - migrated from MomentJS to [Tempo](https://tempo.formkit.com/) (by the FormKit
-team)
-
-> **Note** for the entire list of tasks & code changes applied in this release, you may want to take a look at the [Roadmap to 5.0](https://github.com/ghiscoding/slickgrid-universal/discussions/1482) Discussion.
-
-For most breaking changes, a quick Search & Replace in your code editor should suffice.
-
-> **Note:** if you come from an earlier version, please make sure to follow each migrations in their respected order (review previous migration guides)
-
-## Changes
-
-### Slickgrid-Universal
-If you use any of the Slickgrid-Universal extra dependencies then also make sure to upgrade them as well to the new major `5.0.0` version so that they work with Angular-Slickgrid `8.0.0`
-
-```diff
-  "dependencies": {
--   "@slickgrid-universal/excel-export": "^4.7.0",
-+   "@slickgrid-universal/excel-export": "^5.0.0",
--   "angular-slickgrid": "^7.7.0",
-+   "angular-slickgrid": "^8.0.0",
-}
-```
-
-### Styling
-
-#### CSS classes `.color-xx` are all removed (use `.text-color-xx` or native `color` instead)
-> **Note** these extra colors are only available in the Material & Salesforce Themes (it is not included in the Bootstrap Theme since Bootstrap have their own coloring utils).
-
-Since the SVG icons are now pure CSS, we can now colorize any of them the same way that we would do for any other text via the `color` CSS property 🌈. For that reason, we no longer need any of the `.color-xx` CSS classes (which were created via CSS [filter](https://developer.mozilla.org/en-US/docs/Web/CSS/filter)). They were useful to override the SVG icon colors (by using CSS `filter`), but since we can now use the regular CSS `color` property, the `color-xx` are no longer necessary and were all removed (just use `text-color-xx` instead or plain CSS `color`s).
-
-```diff
-<button class="button is-small">
--  <span class="mdi mdi-undo color-primary"></span>
-+  <span class="mdi mdi-undo text-color-primary"></span>
-   <span class="text-color-primary">Undo Last Edit</span>
-</button>
-```
-or move the class to the parent container and have both the icon & the text `inherit` the color :)
-```diff
-+ <button class="button is-small text-color-primary">
--   <span class="mdi mdi-undo color-primary"></span>
-+   <span class="mdi mdi-undo"></span>
--   <span class="text-color-primary">Undo Last Edit</span>
-  </button>
-```
-
-#### SASS variables
-A lot of SASS variables got changed, we recommend that you take a look at the [_variables.scss](https://github.com/ghiscoding/slickgrid-universal/blob/master/packages/common/src/styles/_variables.scss) file to compare them with your SASS overrides and fix any SASS build issues. For example a lot of the ms-select variables and all Flatpickr related variables were deleted (note that Vanilla-Calendar doesn't actually have any variables). Also a lot of the icon related variables were renamed and updated (all icons now have the suffix `-icon-svg-path` for the SVG vector path, you can easily change them with SASS).
-
-> **Note** if you want to create your own SVGs icons in pure CSS, you could use the `generateSvgStyle()` SASS function from Slickgrid-Universal [`svg-utilities.scss`](https://github.com/ghiscoding/slickgrid-universal/blob/master/packages/common/src/styles/svg-utilities.scss) (take a look at the [`slickgrid-icons.scss`](https://github.com/ghiscoding/slickgrid-universal/blob/master/packages/common/src/styles/slickgrid-icons.scss) for some usage)
-
-#### SASS (dart-sass) `math` polyfills are removed
-When SASS (dart-sass) released their version 1.33 (~3 years ago), it caused a ton of console warnings (and a lot of unhappy users) in projects that were using `/` in their SASS files (for math division) instead of their new `math.div()` function. To avoid seeing all these warnings, I added a temporary polyfill at the time (that piece of code was actually copied from the Bootstrap project). That polyfill patch was put in place about 3 years ago, so I'm assuming that most users have already upgraded their SASS version and already fixed all of these warnings... So, I think it's now safe to remove this polyfill, because like I said earlier, it was really meant to be a temp patch. If you see any warnings coming back, then a suggestion would be to use the SASS CLI `--quiet-upstream` option.
-
-For reference, below is an example of these old Math warnings which were coming up when using the SASS CLI
-
-```sh
-Recommendation: math.div($m, $columns)
-More info and automated migrator: https://sass-lang.com/d/slash-div
-╷
-94 │ margin-right: $m / $columns * 100%
-│ ^^^^^^^^^^^^^^^^^^
-```
-
-#### Font-Awesome references are all removed
-Since this release introduces pure CSS SVG icons, I went ahead and deleted all Font-Awesome references (which were mostly in the Bootstrap Theme). The reason is simple, the built-in icons are now all pure CSS SVG icons (sort, grouping, row detail, row move, row selection). You can also change these icons via SASS (or CSS variables with a bit more work). However, please note that there are a few plugins which use external icons via CSS classes (mostly all menu plugins like Header Menu, Grid Menu, Content Menu, ...) and for that reason **all Styling Themes** now include the Slickgrid-Universal Material icons subset (~200 icons) by default (not just Material & Salesforce but now also the Bootstrap Theme as well). In short, the grid is now using SVG icons by default and Font-Awesome icons will no longer be used internally (you can still use it in your project but it won't be used by the grid itself unless you set them in your grid options).
-
-If you no longer need Font-Awesome, then consider removing it completely
-
-```diff
-# package.json
-{
-  dependencies: {
--   "font-awesome": "^4.7.0"
-  }
-}
-```
-
-What if you don't want to use the [Slickgrid-Universal icons](https://ghiscoding.github.io/slickgrid-universal/#/icons) (`.mdi`) subset and would rather use a different font/SVG library? In that case, I would suggest that you use the "lite" Themes (which do not include the colors & icons subset) and then make sure to update all the menu plugins with the correct CSS classes. For example the global grid options of the Grid Menu is now configured with the following icon classes (notice that we no longer provide any Font-Awesome "fa" icon references in our global grid options). Also note that what is shown below is just 1 of the multiple menu plugins to configure, make sure to review them all (you can review the [global-grid-options.ts](https://github.com/ghiscoding/slickgrid-universal/blob/master/packages/common/src/global-grid-options.ts) file).
-
-```ts
-// default global grid options
-export const GlobalGridOptions = {
-  gridMenu: {
-    iconCssClass: 'mdi mdi-menu',
-    iconClearAllFiltersCommand: 'mdi mdi-filter-remove-outline',
-    iconClearAllSortingCommand: 'mdi mdi-sort-variant-off',
-    iconClearFrozenColumnsCommand: 'mdi mdi-pin-off-outline',
-    iconExportCsvCommand: 'mdi mdi-download',
-    iconExportExcelCommand: 'mdi mdi-file-excel-outline',
-    iconExportTextDelimitedCommand: 'mdi mdi-download',
-    iconRefreshDatasetCommand: 'mdi mdi-sync',
-    iconToggleDarkModeCommand: 'mdi mdi-brightness-4',
-    iconToggleFilterCommand: 'mdi mdi-flip-vertical',
-    iconTogglePreHeaderCommand: 'mdi mdi-flip-vertical',
-  },
-  headerMenu: {
-    // icon...
-  }
-}
-```
-
-and below is a quick snapshot of the file size diff with the "lite" themes (without icons) vs the default themes (with colors & icons subset). However note that the built-in icons are of course always included even in the "lite" themes.
-
-![image](https://github.com/ghiscoding/Angular-Slickgrid/assets/643976/ea7542b9-3c7e-4a6f-ae4d-355138f74188)
-
-### Deprecated code removed/renamed
-##### `getHTMLFromFragment()` removed
-The util `getHTMLFromFragment()` function was removed in favor of `getHtmlStringOutput()`, the new function will auto-detect if it's a DocumentFragment, an HTMLElement or an HTML string and will execute the appropriate action.
-
-##### jQueryUI CSS classes leftovers
-There were a few remaining traces of jQueryUI CSS classes like `.ui-state-default` and other similar classes in the core lib, they were all removed in this release. If you were querying any of them in CSS for styling purposes, you can simply rename them to `.slick-state-*`
-
-```diff
-- .ui-state-default, .ui-state-hover {
-+ .slick-state-default, .slick-state-hover {
-}
-```
-
-### Formatters Cleanup & Removals
-
-Since we now use SVGs everywhere and we got rid of any Font usage (no more Font-Awesome code anywhere), the `checkmark` Formatter no longer has any reason to exist and was removed. If you were using it and still plan to use Font-Awesome in your project, then you'll have to either recreate the Formatter yourself or use alternatives. You could use the `Formatters.icon` or `Formatters.iconBoolean` which require the CSS classes to be provided via `params`. Or as a last alternative, and if you are importing the optional SVG icons `.mdi` subset, then we recommend you simply switch to the `checkmarkMaterial` Formatter.
-
-```diff
-this.columnDefinitions = [
-  {
-    id: 'isActive', name: 'Active', field: 'isActive',
--   formatter: Formatters.checkmark
-+   formatter: Formatters.checkmarkMaterial
-  },
-];
-```
-
-or create a Custom Formatter
-
-```ts
-// create a custom Formatter and returning a string and/or an object of type FormatterResultObject
-const myCheckmarkFormatter: Formatter = (row: number, cell: number, value: any, columnDef: Column, dataContext: any) => {
-  // via native HTML (for CSP safe), you could also use our `createDomElement()` util for 1 liner
-  const iconElm = document.createElement('i');
-  iconElm.className = value ? 'mdi mdi-check' : '';
-  return iconElm;
-
-  // or via simple HTML string
-  return value ? '<i class="mdi mdi-check"></i>' : '';
-}
-```
-
-## Column Functionalities
-
-### Native Select Filter (removed)
-I would be very surprised if anyone had ever used the `Filters.select`, which was a native `<select>`, and so it was removed in this release. You should simply use the `Filters.singleSelect` or `Filters.multipleSelect`
-
-```diff
-prepareGrid() {
-  this.columnDefinitions = [{
-    id: 'isActive', name: 'Active', field: 'isActive',
-    filter: {
--      model: Filters.select,
-+      model: Filters.singleSelect,
-       collection: [ { value: '', label: '' }, { value: true, label: 'true' }, { value: false, label: 'false' } ],
-    }
-  }];
-}
-```
-
-### Date Editor/Filter
-Since we migrated from Flatpicker to Vanilla-Calendar-Pro, this requires some changes on your side because the setting option names are different. Same changes will be required for both the Filter and the Editor.
-
-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:
-
-```diff
-- import { type FlatpickrOption } from '@slickgrid-universal/common';
-+ import { type VanillaCalendarOption } from '@slickgrid-universal/common';
-
-prepareGrid() {
-  this.columnDefinitions = [{
-    id: 'finish', field: 'finish', name: 'Finish',
-    editor: {
-      model: Editors.date,
--      editorOptions: { minDate: 'today' } as FlatpickrOption,
-+      editorOptions: { range: { min: 'today' } } as VanillaCalendarOption,
-    }
-  }];
-}
-```
-
-> **Note** visit `Vanilla-Calendar-Pro` [settings](https://vanilla-calendar.pro/docs/reference/additionally/settings) website for all other options.
-
-> **Note** to keep docs available for older as well as newer versions, I renamed the old one doc as [Date-Picker (flatpickr)](https://ghiscoding.gitbook.io/slickgrid-universal/column-functionalities/editors/date-editor-flatpickr) and created a new one named [Date-Picker (vanilla-calendar)](https://ghiscoding.gitbook.io/slickgrid-universal/column-functionalities/editors/date-editor-vanilla-calendar).
-
-### `internalColumnEditor` is completely removed
-The work on this subject started over a month ago in version [v4.6.0](https://github.com/ghiscoding/slickgrid-universal/releases/tag/v4.6.0) to progressively remove `internalColumnEditor` because it was confusing and with this new release, it is now completely removed. This mean that the column `editor` property will remain untouched (in previous releases, the `editor` was moved to an `internalColumnEditor` prop and `editor` was then overriden with the `editor.model` and that was for SlickGrid to work properly... but that was extremely confusing to the user). So in short, the `internalColumnEditor` is now completely removed and the associated confusion is also gone with it.
-
-A good example of the previous `internalColumnEditor` usage, was when you wanted to modify or push a new item to the editor collection array (see below). In the past, you could not simply push to the `collection.editor.collection` because the property was swapped internally. What you really had to do was to use the mapped `collection.internalColumnEditor.collection` 😵... and this is now thankfully gone, you can now use the same and original `collection.editor.collection` 👍
-
-For example, previously, to add an item to the editor/filter collection
-```diff
-this.columnDefinitions = [{ id: 'complexity', editor: { model: Editors.singleSelect, collection: [{ value: 1, label: 'Simple' }, { value: 2, label: 'Hard' }] } }];
-
-// then adding an item was previously requiring to use the `internalColumnEditor`
-// that is, after the grid init our `editor` became `internalColumnEditor
-- const complexityEditor = this.columnDefinitions[0].internalColumnEditor;
-complexityEditor.collection.push({ value: 9, label: 'Hard' });
-
-// NOW with this new release, adding a new item to the collection is as simple as referencing the original object
-+ const complexityEditor = this.columnDefinitions[0].editor;
-complexityEditor.collection.push({ value: 9, label: 'Hard' });
-```
-
-if you want to reference the Editor class (e.g. `Editors.longText`), you can now get it from either `column.editor.model` or `column.editorClass`
-
-## Grid Functionalities
-
-### Sanitizer (DOMPurify)
-`DOMPurify` is now completely optional via the `sanitizer` grid option and you must now provide it yourself. The main reason to make it optional is because even though most users would prefer to use `dompurify`, some might prefer to use `isomorphic-dompurify` for SSR support. Consider that it is now optional, you could also technically speaking skip the `sanitizer` configuration completely, but that is not at all recommended.
-
-> **⚠ Note** even if the `sanitizer` is now optional, we **strongly suggest** that you configure it as a global grid option to avoid any XSS attacks from your data and also to remain CSP compliant. Also note that for Salesforce users, you do not have to configure it since Salesforce already use DOMPurify internally.
-
-```diff
-// prefer the global grid options if possible
-this.gridOptions = {
-  sanitizer: (dirtyHtml) => DOMPurify.sanitize(dirtyHtml, { ADD_ATTR: ['level'], RETURN_TRUSTED_TYPE: true })
-};
-```
-
-> **Note** If you're wondering about the `ADD_ATTR: ['level']`, the "level" is a custom attribute used by SlickGrid Grouping/Draggable Grouping to track the grouping level depth and it must be kept for the group indentation to work properly.
-
-### From MomentJS to [Tempo](https://tempo.formkit.com/)
-I really wanted to replace MomentJS for a long timeeee... (it's been deprecated for years and is CJS only), but it was really hard to find a good replacement (I tried many alternatives like `DayJS`, `Luxon`, `date-fns` and they all had problems at least for a datagrid use case where parsing & formatting is important)... and here comes [Tempo](https://tempo.formkit.com/)! With Tempo, I was finally able to migrate by taking advantage of their `parse()` and `format()` functions, which are the most important in a datagrid usage. The library also has plenty of extra, and optional, functions as well, for example `addDay()`, `diffDays()`, ... Another great thing about Tempo is that they use the same format/parse [tokens](https://tempo.formkit.com/#format-tokens) as MomentJS, so the conversion on that side was super easy.
-
-The migration to Tempo should be transparent to most users like you. **However** if you are currently using MomentJS in your project, then I would suggest you to consider trying [Tempo](https://tempo.formkit.com/) in order to modernize your project and also lower your dependencies count. The other great advantage of Tempo is that it's ESM and it helped a lot in decreasing our build size footprint because ESM also means that it is Tree Shakable (only import and build what you use). By using Bundlephobia and comparing [@slickgrid-universal@4.7.0](https://bundlephobia.com/package/@slickgrid-universal/common@4.7.0) we can see that `moment-mini` is taking 41.5Kb, while Tempo takes only 16.6Kb in [@slickgrid-universal@5.0.0](https://bundlephobia.com/package/@slickgrid-universal/common@5.0.0), that is a decrease of almost 25Kb (ESM makes a huge difference).
-
-### `allowedCommonJsDependencies`
-Lastly since we got rid of MomentJS and replaced Flatpickr, you can remove a few dependencies from your `allowedCommonJsDependencies` in your `angular.json`.
-
-```diff
-{
-  "allowedCommonJsDependencies": [
-    "dompurify",
--   "flatpickr",
--   "moment-mini",
-    "stream"
-  ],
-}
-```
-
-### Smaller Size - Full ESM
-
-To compare size, you can take a look at BundlePhobia for the older [v1.4.0](https://bundlephobia.com/package/@slickgrid-universal/common@1.4.0) (when we required jQuery/jQueryUI) and [v5.0.0](https://bundlephobia.com/package/@slickgrid-universal/common@1.4.0) and you'll see that the gzip version went down by 17Kb (or 8.9%) and that's just for 1 dependency of the Slickgrid-Universal workspace (there's a few more installed behind the scene, like the footer component, binding, utils, ...). From that website you can also see that removing MomentJS & Flatpickr had a significant impact in decreasing build size, especially since the replacements are ESM and tree shakable.
-
-### Excel Export `valueParserCallback`
-I would be very suprised if anyone used this advanced feature BUT in case you do, I have decided to make some breaking in v5.1 and higher for the Excel cell value parser after creating the new [Example 36](https://ghiscoding.github.io/Angular-Slickgrid/#/excel-formula) and that is mostly because we now have way too many arguments provided to these value parsers. So, this mean that both `excelExportOptions.valueParserCallback` and `groupTotalsExcelExportOptions.valueParserCallback` signatures changed as shown below.
-
-```diff
-this.columnDefinitions = [
-  {
-    id: 'cost', name: 'Cost', field: 'cost', width: 80,
-    excelExportOptions: {
--     valueParserCallback: (data, col, excelFormatId, excelStylesheet) => {
-+     valueParserCallback: (data, { columnDef, excelFormatId, stylesheet }) => {
-        return `Total: ${data}`;
-
-        // to keep Excel style format, you can use detected "excelFormatId" OR use "stylesheet.createFormat()"
-        return {
-          value: isNaN(data as number) ? data : +data,
-          metadata: { style: excelFormatId } // the excelFormatId was created internally from the custom format
-        };
-      }
-    },
-    groupTotalsExcelExportOptions: {
--     valueParserCallback: (totals, columnDef, groupType, excelFormatId) => {
-+     valueParserCallback: (totals, { columnDef, excelFormatId, groupType, stylesheet }) => {
-        const fieldName = columnDef.field;
-        //return totals[groupType][fieldName];
-
-        // or with metadata
-        return { value: `totals[groupType][fieldName]`, metadata: { style: excelFormatId } };
-      },
-    }
-  }
-];
-```