Future ideas for next features in v4.x

[ghiscoding]

• 1. migrate Excel-Builder-Webpacker fork to TypeScript and provide CJS/ESM builds with Tree Shaking (ref PR feat(ExcelExport): migrate to Excel-Builder-Vanilla (ESM) #1383)
  • move the code to a new repo Excel-Builder-Vanilla
  • drop Q and Lodash dependencies and possibly replace JSZip with fflate
• 2. replace node-archiver (to create bundle zip used in Salesforce) by either JSZip or fflate (ref PR chore: migrate from node-archiver to fflate to zip standalone SF bundle #1387)
  • need to be tested in Salesforce
• 3. autocompleter is not fully ESM, I think it could be fixed with a simple PR on the project since it already uses Rollup but currently only build as umd, we simply need to add Rollup es build
  • PR creates, just waiting for author's review & merge. I might create a temp fork if I don't have any answer a month from now
  • waited 1.5 months and decided to eventually release autocompleter-es until my PR is merge/release (which of course got merged 1 day after I created the fork lol)
• 4. Dark Mode theme (ref PR feat(styling): add Dark Mode grid option #1407)
• 5. possible Vue port
• 6. CustomTooltip plugin only works against 1 cell content but doesn't work well if we have a cell with multiple icons that each have tooltips (e.g. Example 11, 22)... (ref PR fix(tooltip): allow multiple tooltips per grid cell #1448)
• 7. deprecate editor model in a way to add back original SlickGrid editor type
  • we could rename the SlickGrid editor option to editorFactory (or editorClass) so that wouldn't be a breaking change to users
• 8. we could show ms-select clear button for clearing the filter (see showClear option)
  • only show as a filterOptions to Example 11-12
• 9. small Dark Mode tweaks
  • add Flatpickr box-shadow: 0 2px 6px rgb(255 255 255 / 20%) to make the picker pop a little more
  • see if we can use SVG for ms-select to make it a bit more modern (like Bulma/Bootstrap Dropdown)
  • tweak uncheck column color
  • we barely see the checkbox border after new version in Example 12
  • small styling issue in Example 7 Dark Mode when filtering date/input, the filter text color is gray instead of white. Should also change SF button primary color to more lighten color (longText/compositeEditor), use same color as header bar border bottom color
• 10. review again package exports, use same as ms-select lib, see are the types wrong
• 11. might be nice to have a way to add default settings for external editor/filter (autocomplete, ms-select, flatpickr, slider)
  • ref PR feat(common): add global defaultEditorOptions & defaultFilterOptions #1470
  • perhaps something along the lines of (we would have 2 props defaultEditorOptions and defaultFilterOptions)

this.gridOptions = {
  defaultEditorOptions: { 
    autocompleter: { debounceWaitMs: 150 }, 
    date: { minDate: 'today' },
    longText: { cols: 50, rows: 5 } 
  }
}

New Discussion

Breaking Change or Postponed Changes were moved to this other Discussion Roadmap to 5.0

[ghiscoding]

hello @zewa666 I'd like some feedback on number 12 (now 7) from your side. I'd like to rename the SlickGrid editor, not the Slickgrid-Universal one but really the one SlickGrid uses. What's the difference you may ask? The difference is that in Slickgrid-Universal (or upstream repos), the editor is where we can add extra properties like minValue, collection, ... However for SlickGrid the editor is really the Editor Class, so that would be Editors.LongText class for example (so in Slickgrid-Universal, it's the editor.model property). The fact that both projects used the same prop name caused some conflicts which I had to address by internally by copying the user's editor into my own internal ref internalColumnEditor and overwriting the editor with editor.model so that SlickGrid work as intended. Basically I went that way to make it easier for the users because I didn't think of a better prop name editor to expose to the users (and also because I used the same for filter prop as well).

slickgrid-universal/packages/vanilla-bundle/src/components/slick-vanilla-grid-bundle.ts

Lines 1455 to 1479 in 21c76cc

	/**
	* For convenience to the user, we provide the property "editor" as an Slickgrid-Universal editor complex object
	* however "editor" is used internally by SlickGrid for it's own Editor Factory
	* so in our lib we will swap "editor" and copy it into a new property called "internalColumnEditor"
	* then take back "editor.model" and make it the new "editor" so that SlickGrid Editor Factory still works
	*/
	protected swapInternalEditorToSlickGridFactoryEditor(columnDefinitions: Column<TData>[]): Column<TData>[] {
	const columns = Array.isArray(columnDefinitions) ? columnDefinitions : [];
	if (columns.some(col => `${col.id}`.includes('.'))) {
	console.error('[Slickgrid-Universal] Make sure that none of your Column Definition "id" property includes a dot in its name because that will cause some problems with the Editors. For example if your column definition "field" property is "user.firstName" then use "firstName" as the column "id".');
	}
	return columns.map((column) => {
	// on every Editor that have a "collectionAsync", resolve the data and assign it to the "collection" property
	if ((column.editor as ColumnEditor)?.collectionAsync) {
	this.loadEditorCollectionAsync(column);
	}
	// if there's already an internalColumnEditor we'll use it, else it would be inside the editor
	const columnEditor = column.internalColumnEditor || column.editor as ColumnEditor;
	return { ...column, editor: columnEditor?.model, internalColumnEditor: { ...columnEditor } };
	});
	}

However, now that Slickgrid-Universal is a standalone, I'm thinking about removing this internal properties swap by simply renaming the SlickGrid editor to another name, that is where I'd like to have feedback. At first I was thinking about editorFactory but in reality it's not really a factory since it's the Editor Class, so maybe a better name is editorClass!? Do you have a better name? Then internally, I will copy the editor.model into that new name, so possibly doing this: editor.name => editorClass

At the end of it, that will cleanup the code and more importantly, that will avoid the need for that internal swap that I was doing (better perf and less error prone). There will be a small change to the users who were referencing internalColumnEditor (which equal to the editor.model), they will simply be able to use editor directly in the future without it being overwritten (which was confusing for some), so it would equal to the same as what they define in their column definitions (which is not the case currently)

so... any name suggestion other than editorClass for the one used by SlickGrid? Note that I don't want to be too far from the original SlickGrid because I keep track of whatever PRs is being created and replicate them here when it makes sense

[ghiscoding]

hmm I'm not following much of the new Angular stuff, if you want to modify some of the examples go ahead but I don't think that I will myself ;)

I just tried a quick date parsing last night with Luxon and so far not really impressed, even though some of its author came from Moment, they don't even use the same parsing token (e.g. YYYY-MM-DD is yyyy-MM-dd in Luxon) and it seem to require a lot of different method to deal with parsing and formatting (similar to date-fns I guess). I might give another try at DayJS, they are closer to Moment than any other lib but it's barely maintained now and I remember Zulu wasn't working in strict mode, though that might not be a big issue. I wish date-fns would fix that PR I pointed out... man at the end of the day all I need is parsing/formatting with specific tokens provided to force a certain format for both parsing/formatting, that's all I need in a datagrid (I don't care about any of the date locale stuff)

[zewa666]

to be honest I never understood the convention of casing tokens. according to the ISO definition it all upper caps for the date tokens and lower caps for the time part. but its just a recommendation used for samples. the icu (collection of locales) on the other hand uses the later format, as Luxon https://icu4c-demos.unicode.org/icu-bin/locexp?_=en_CA&d_=de&d_l=en same with languages like C#. I get your frustration but ultimately those details are dictated by the lib used, so I'd merely add a note to the token examples of the respective docs

[ghiscoding]

yeah I know, it should be totally transparent to the user since these are mostly internal function mapping that I have and the user just defines a type.dateEuro and such, then the mapping function assigns the correct token. My frustration is mostly that I still can't find a good replacement for MomentJS. My plan for the long run is to be full ESM eventually (because one day or another ViteJS will be ESM only) and Moment is mostly the last hurdle left to convert (well apart from Flatpickr and DOM Purify but they are less of a problem)

[zewa666]

so if you'd fork moment-mini and add a simple esm wrapper on top of cjs would that work instead?

[ghiscoding]

ah yes I don't know why I never thought of that but yes that would work, perhaps this @esm-bundle/moment package. I also read their blog post An ESM bundle for any NPM package about @esm-bundle, it's interesting, so I might give that a try, that might be the easiest solution if it works :)

[ghiscoding]

on another subject, I've done some research about Temporal and it doesn't (and never will) have any parser so even if it's released tomorrow, I don't think I could use it out of the box. At some point I tried migrating to DayJS but it has problem with Zulu and most importantly it doesn't have an ESM builds (Luxon has the same problem). Last weekend, I tried to migrate to date-fns, it was going ok until I came across the missing non-strict mode in a comment that I described here, so it looks like I'm stuck with MomentJS for the short term. I wish that they would implement the strict flag but that issue has been opened since 2019, so I'm not sure that it will be implemented any time soon (but let's keep dreaming). The non-strict is a real blocker in a datagrid environment

[zewa666]

hmm from a quick look it seems luxon does support esm https://github.com/moment/luxon/blob/895a74916a89f816de7c98e912ae9140c6327897/package.json#L11 and can parse zulu times with parseIso + setZone mixes moment/luxon#988

[ghiscoding]

For Luxon, it's not quite true, they apparently have a problem with their build and it's not fully ESM (at least not fully tree shackable) as per this issue that was never resolved. So I don't want to go with a migration that will not fully work and/or increase the size (I use moment-mini which is not that big at 57Kb minified). At this point, it seems that every libs I tried have their own different problems :(

Nonetheless, Luxon is the only one I didn't try yet, I might as well give it a try and see for myself... to be continued

[ghiscoding]

so.... on this MomentJS saga, I found out that Moment already transpiles an ESM build since 2020 as per this commit, so I was thinking... let's use that then!? Well it's not exactly the best since the biggest reason I switched to moment-mini was because by default and without any tricky WebPack configuration, all Moment locales will be included (and there's a lot of them). So I switched to moment-mini a while ago for that reason. The problem with moment-mini is that they only include the CJS build (moment.js from the project root), so... I created yet another repo moment-tiny which is similar to moment-mini but with both CJS and ESM builds... and finally I can remove Moment from Angular's allowedCommonJsDependencies and it works. More info on moment-tiny repo.

Also note that even if Moment includes an ESM build, it could be better, one of their biggest disadvantage is that they export everything as default (which is discouraged by TypeScript and requires allowSyntheticDefaultImports)... but anyway, that should suffice for the next couple years. Maybe some day Temporal will be released and someone will create a great parser with all the tokens needed for my project (someone can dream lol)... or maybe date-fns will address the missing non-strict parsing.

So anyway, I can finally close the subject for now. I'm wondering if I should postpone that for the next major version though since some user might reference moment-mini in their project... but I'm really tempted to go with just minor version since I'm not crazy about waiting 2 months and technically speaking the user will have the dependency in their package.json if they import a dep, so what do you think? Also version adoption is super slow by users of my libs so.. (ref PR #1456)