Future Ideas and possible features

[ghiscoding]

Below is a list of ideas, there's a good change that it will never come to fruition but I'm just listing them as possible ideas anyway

• 1. Vue port, possible refs:
  • https://mokkapps.de/blog/simpler-two-way-binding-in-vue-with-define-model
  • https://medium.com/@dev.alberthoxha/define-model-is-stal-in-vue-3-4-0f25588f5686
• 2. PDF Export, see UI-Grid data export and in code
• 3. row span, see comments and GerHobbelt initial commit
• 4. we only have 1 preheader, so this mean we can't use simple features that use the same preheader because of the conflicts (DraggableGrouping/HeaderGrouping)
  • ref PR feat(core): add optional Top-Header for Drag Grouping & Header Grouping #1556
• 5. possible use of Web Worker for Export Services to avoid blocking main thread while downloading
  • gave it a try but it doesn't look feasible since Web Workers don't even work with binding scope, it only works with local code that has no connection (scope) to the outside which seems impossible in here since we need to use the SlickGrid/DataView variable bindings to read every row and all kind of other things
• 6. Infinite Scroll for Backend Services (see Ag-Grid Infinite Row Model)
  • PR feat: Infinite Scroll for Backend Services #1609
  • PR feat: add Infinite Scroll with local JSON data #1628
• 7. try to use SortableJS ESM import and see if it helps with build size
  • import Sortable from 'sortablejs/modular/sortable.core.esm.js'; (see SortableJS Getting Started)
  • make sure Column Reordering and Draggable Grouping also still works
  • currently makes 2/3 of unit tests to fail in PR perf: use SortableJS ESM import to save 1kb #1621 because Jest only supports CJS, so I'll cancel this for now but might revisit if migrating to Vitest with full ESM
  • EDIT: I gave it another try after migrating to Vitest and sortable.core.esm.js doesn't play well with current Types @types/sortablejs because the names don't match. Considering that this is a pain to get proper Types, I think I'll just keep current approach and 1kb bigger is not that much of a difference. The hope is that one day, SortableJS offers better ESM support (but I won't put much hope on this happening anytime soon sadly)
• 8. drag rows between 2 grids and/or drag row to outside container like a recycle bind
  • 1. between 2 grids (won't do since this requires a new plugin and no one ever requested this feature), alternatively any user could simply create their own plugin themselves.
  • 2. drag rows to recycle bin
• 9. stop using Jest Global types, see this potential PR of another project to handle it Migrate to Vitest instead
  • ref PR chore: migrate from Jest to Vitest for ESM support #1663
• 10. can we further improve Date Sorting speed (perf)? (see if we can use other sorting type for large dataset, i.e. quick sort)
  • ref PR perf: option to improve Date Sorting by pre-parsing date items only once #1691
  • see these articles Sorting Algorithms in JavaScript or TypeScript / Introduction to Sorting Algorithms in JavaScript
• 11. custom pagination is not currently replaceable by the user, but it probably should be eventually to be fully customizable
• 12. add silenceWarnings to all ports in next version only
• 13. I think that GroupingAndColspanService should be renamed to HeaderGroupingService since there's nothing related to colspan (the colspan was actually meant to represent that header can span across multiple columns, but SlickGrid always called it Header Grouping, so let's use that name instead in the next minor version)
• 14. we should probably add peer deps to all ports, for example: "peerDependencies": { "react": ">= 18.0.0" }

next potential major version ideas

• 20. drop CJS? Yep we'll schedule it for our next major release around Node 18 EOL
  • this would require migrating from Jest to Vitest (ref PR chore: migrate from Jest to Vitest for ESM support #1663)
• 21. deprecate rowTopOffsetRenderType and use transform in next major release
  • see PR perf: add new rowTopOffsetRenderType grid option to use "transform" #1650
• 22. possibly switch to column hidden property, which we tried in the past via this SlickGrid PR. It could be an issue in ColumnPicker/GridMenu, requires more in depth testing
• 23. drop Node 18 and upgrade dependencies that require Node 20
• 24. remove internal deep copy of GridOption and allow user to update any options by pointer or reference
  • see this Angular-Slickgrid issue for more context
• 25. rename previous CRUD singular names to plural names and always return an array
  • onItemAdded, onItemDeleted, onItemUpdated, onItemUpserted
• 26. provide an ESM only PR to un-flatten-tree repo, or fork the project as a last resource (only if future PR of ESM isn't accepted)
• 27. in Angular-Slickgrid, we should probably:
  • switch to Vite builder, https://angular.dev/tools/cli/build-system-migration
  • upgrade ngx-translate, https://ngx-translate.org/getting-started/migration-guide/
  • potentially upgrade to Angular 19
• 28. in Slickgrid-React, we could:
  • upgrade to React 19 if it's out (currently in RC, not official yet), see their blog post
  • major upgrade i18next to v24 and i18next-http-backend to v3 (same for Aurelia-Slickgrid)
• 29. in Aurelia-Slickgrid, we could:
  • migrate dev from WebPack to ViteJS, need to make sure this doesn't impact users of WebPack afterward though
• 30. perhaps @formkit/drag-and-drop might be a good alternative to SortableJS which doesn't provide an out of the box ESM (they provide sortable.core.esm.js but it breaks @types/sortablejs, which isn't ideal)
• 31. upgrade to new major version of Vanilla-Calendar-Pro v3, see vanilla-calendar3 branch, however it's missing changes for the use of the new .set() method (see comment)
• 32. possibly use the modern and simpler Clipboard API instead of creating temp textarea to fake a copy
  • we have 2 places where this is being used, inside SlickExternalCopyManager and in SlickContextMenu (copy cell)
  • see SlickGrid branch
  • see WebSchool - JavaScript Clipboard API
  • actually this can be simplified by using this implementation SO
• 33. possibly move node-extend from utils/nodeExtend to a separate npm org for utils, maybe @universal/node-extend or something similar, the reason is mostly because node-extend have no intention of going ESM as per this node-extend issue and I want to move it outside of the Slickgrid-Universal world so that other users can take advantage of an ESM package (or maybe even myself in projects not requiring SlickGrid)
• 34. could we try to move some, or all, extensions as optional and maybe do something similar to what I've done in Lerna-Lite code which is to use await import(plugin). I'm guessing that ViteJS is potentially doing similar with SASS which is optional but then it works as postCSS when installed. \
• 35. CSP is now supported in ViteJS Dev mode, we should look at adding it to our Development phase, see ViteJS CSP
• 36. potentially create a frameworks folder in the workspace and provide optional install for each frameworks in readme via pnpm install --filter
  - will require GitBook in Monorepo changes
  - will also require some changes to deployed demo for each framework, maybe this article would help: Deploying Multiple Apps From a Monorepo to GitHub Pages