updating to node ES6

[DimitarChristoff]

So, not sure if this is a desired goal or not but...

Consumption of SlickGrid in a modern project that is driven by npm and built via webpack/babel/ES6 can be a pain in the backside, given the reliance on globals, order of loading, lack of implicit dependencies.

I got annoyed and took out the bits from the repo one by one and added them to a new repo, converting in the process.

It's WIP - https://github.com/DimitarChristoff/slickgrid-es6 - but it occurs to me, it can probably be done as a fork of this instead of a fresh standalone effort. If this sort of direction is something of interest, ping me and we can convert and do stuff as a pull request and an actual fork of 6pac/SlickGrid.

TL;DR; took your repo, made it work with node/ES6, removed IE8, moved to jquery 3.1.0, all deps are npm, works fine in React or whatever.

[6pac]

that would interest me.
i've been working on a bower file, and that has brought up the jquery 1/2/3 issue.
someone else has offered a pull with the changes to bring over all the deprecated events for 3 to the new equivalent forms, and i'm presently testing the codebase to make sure this all works with jquery 1.7+ (1.7 being the version MLeibman's branch is still at). the new forms of these events appear to exist in 1.7, so I'm trying to support 1.7+
then the bower file will follow. never used npm myself, so i'm not sure of the relationship there (i know bower depends on npm).
one question - when small updates are made, would you see yourself applying them to the es6 branch, or would you expect me to do that?

[DimitarChristoff]

i am more concerned with going forward and performance than backwards compatibility, to be fair - which may mean misaligned goals.

for example, I am currently looking at deprecating jquery-ui and event.drag/drop stuff in favour of http://interactjs.io/ - interact.js is very small, portable, framework agnostic, performant and touch friendly. the only awkward stuff is sortables, which may remain using ui/widgets/sortable.js for now.

bower depends on a combo of github tagged releases + bower.json, not npm (or used to, been a while since I used it) - the two versions can be misaligned.

support for that can work fine. in terms of npm deps, it works fine but because it's effectively closures and multiple versions of the same package can exist (unlike bower flattening all deps), things that rely on extending globals like $.fn etc may not work as expected so it's slow going. right now the grid works fine cept for the column resizing, which breaks because of old code relying on decorating $event.fixHooks and event.drag is in conflict with stock jquery-ui.

anyway, will keep you posted and show you a more stable version soon, it's a few of us looking at it so we should have some progress soon.

[morphean]

+1, switching to npm just makes life easier for everyone. and bower feels like legacy these days. and if this is released as a major version bump then it is quite clear that there are potential breaking changes (re: semver)

[6pac]

it may be time to create a new repo for the forward-looking fork and diverge from the backwards compatible one. i understand that it's probably not possible to keep both in the one fork.
several people have discussed deprecating event.drag, but it's complicated (#14, #15). if you can make it work, that would be a welcome addition.
i'm probably mixing up the fact that i had to use npm to install bower. it could be that the program itself is dependent on npm, but not the bower processes. don't see why we can't have a bower file too, though.

[DimitarChristoff]

yeah agreed re bower. as for deprecation of event.drag, I have fully
working column resize with interact.js and currently deprecating UI
sortables for column reorder, but this is more complex.

I don't mean cut the umbilical cord but keep the top level API intact, more
or less.

will post something when I have it working, a few issues around edge cases
on forceFit and minWidth and maxWidth but looking good.

On Thursday, 21 July 2016, Ben McIntyre notifications@github.com wrote:

it may be time to create a new repo for the forward-looking fork and
diverge from the backwards compatible one. i understand that it's probably
not possible to keep both in the one fork.
several people have discussed deprecating event.drag, but it's complicated
(#14 #14, #15
#15). if you can make it work,
that would be a welcome addition.
i'm probably mixing up the fact that i had to use npm to install bower. it
could be that the program itself is dependent on npm, but not the bower
processes. don't see why we can't have a bower file too, though.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#41 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAHSzPItNYPfpldQV4rb9IvHi3hdg7c4ks5qX1wBgaJpZM4JQqWk
.

Dimitar Christoff

"JavaScript is to JAVA what hamster is to ham"
@D_mitar - https://github.com/DimitarChristoff

[DimitarChristoff]

ok this now works on my remote branch.

https://github.com/DimitarChristoff/slickgrid-es6/tree/interact-js - you can play with it by forking repo, checking out the branch and running npm start after npm install

https://github.com/DimitarChristoff/slickgrid-es6/pull/1/files is the diff - once again, WIP but it now has column reorder and resize and no external deps other than interact.js

then open http://localhost:8888/ and pick an example like 1 or 3 and play with it. hot reloading is enabled.

[6pac]

Thanks Dimitar, I have now completed integration of the updates for the existing repo to work with jQuery 3. I'm now tidying up some of the smaller issues. Since your changes are major, I'll probably look at them in a couple of weeks. Just keeping you in the loop.

[ZheyangSong]

+1. I simply would like to see this awesome library can support AMD-like environment. And I found a possibly unmaintained repo (https://github.com/sortex/amdjs-SlickGrid). It's not been updated since several years ago and definitely is lack of new features from this repo. Can we expect some solution on making this well-maintained library work with AMD-like environment? (No well-trained developer/engineer likes global variable pollutions nowadays) :)

[6pac]

@ZheyangSong we have had a few requests for various package managers, which I'm working through.
I'm not personally that keen on AMD, and it would have an impact on the codebase making it harder to use for non-AMD projects. The changes in the repo you mention are pretty clear and simple and fall in a single commit. I'd suggest turning them into a patch and then applying that patch to this repo or the repo of your choosing. Hey presto! an AMD compliant branch!
I suppose I could do this on a branch of my repo, but it's just '1 more thing' (TM). But seriously, I'd be maintaining about 10 separate branches if I did this for everyone who asked.
You are free to fork this repo, add AMD and keep it up to date. I'm happy to point people at that in my wiki.

[DimitarChristoff]

you can use UMD and set build target to that but it can be annoying when
deps like jquery-ui are completely non compliant and need special requirejs
configurations to get going.

On Tuesday, 23 August 2016, Ben McIntyre notifications@github.com wrote:

@ZheyangSong https://github.com/ZheyangSong we have had a few requests
for various package managers, which I'm working through.
I'm not personally that keen on AMD, and it would have an impact on the
codebase making it hard to use for non-AMD projects. The changes in the
repo you mention are pretty clear and simple. I'd suggest turning them
into a patch
https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/
and then applying that patch to this repo or the repo of your choosing. Hey
presto! and AMD compliant branch!
I suppose I could do this on a branch of my repo, but it's just '1 more
thing' (TM)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#41 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAHSzCG6eADYyWvpvYl1uMuK2oxTsXuwks5qilcagaJpZM4JQqWk
.

Dimitar Christoff

"JavaScript is to JAVA what hamster is to ham"
@D_mitar - https://github.com/DimitarChristoff

[piyushgupta1]

@DimitarChristoff Great work. I am already using the your fork in one of my projects. At which version did you fork this repo ?

[ghiscoding]

Better late than never, this issue has been resolved in v5.0, our source code was migrated to TypeScript and we now use esbuild to build 3 different build targets (iife, cjs & esm) which closes this issue, see SlickGrid 5.0 Announcement & Migration for more info and take a look at the top of the Examples page for new ESM examples