Migration of SlickGrid to TypeScript

[Danielku15]

I am following up here the discussion of #572, I think it is worth having an own dedicated issue for that 😉 @6pac @ghiscoding

It would be worth a consideration to migration SlickGrid to a typescript codebase and try to modernize the codebase by eliminating some dependencies of which some are maybe even unmaintained.

Some benefits on that:

• A more modern tech-stack attracts more developers to contribute. Getting new devs bootstrapped and accomodated with the SlickGrid development environment is eaiser this way.
• Providing libraries for other projects becomes easier (NPM, TypeScript definitions,..)
• Dependency management gets more visible
• Removing jQuery makes it more attractive for new frameworks like Angular, React etc. which usually avoid jQuery.
• Test infrastructure, documentation etc. is easier to maintain.
• Code quality overall can be improved (TSDoc, TypeSafety, OOP development style, module system compatibility,..)

If there is a strategy in this regards, I could try to prepare a basic infrastructure based on my own project which provides bundling, CI/CD scripts, etc. Or you just peek into my structure as a first idea:

It might have a bit more than SlickGrid will need. But especially setting up rollup, typescript, karma, incremental compilation etc. took me a bit, but now it's really smooth (to me at least 😁 ).

• https://github.com/CoderLine/alphaTab/
• https://alphatab.net/docs/contributing

[ghiscoding]

Right.. since I had the button I could do it lol 🤦‍♂️
I'll hide your last comment in a bit to cleanup the discussion. Thanks

[ghiscoding]

Feel free to start a new branch for this work if you want, we could cooperate on that same branch.

@6pac would you be ok with that kind of approach?
I did mention in the other post that we can target multiple bundle (ES5, ESM, CommonJS, UMD) to get it working in every environment (old and new), so that shouldn't be a worry to have it all working, the only difference might be how you import the file that might (probably would) change. How do you load them on your side anyway? Just script tag or..?

[6pac]

Agree on all of these, other than that I'm dreading getting rid of the drag/drop libs. It may have evolved, but last time I looked browser support and third party libraries were all over the place with feature support and feature implementation.
Also I generally follow the practice of putting var self = this; at the start of a declaration where this needs to be used consistently. I think policies around this kind of language construct can avoid a lot of the issues, which I agree can be very subtle and hard to diagnose.
I'm currently searching for some subcontractors or employees, it could possibly be something a junior developer could churn through. Would actually also be an awesome learning exercise.

[6pac]

can't help wondering if the jquery elimination could be largely accomplished with some advanced pattern recognition engine, like a successor to GREP.

[ghiscoding]

it's not that easy to replace jQuery, it's better to do it by hand because querying with jQuery will always return a jQuery object for chaining purposes (even when the element doesn't exist) while in plain JS it will return undefined, so there's more work to make sure you're not trying to read an object property from undefined which won't work, but with jQuery it wasn't much of a problem... oh and the chaining is also a missing piece since I just talked about it. Another thing that jQuery provides is event namespace, which I use in the auto-resizer plugin here $(window).on('resize.grid.' + _gridUid, I don't think there's any equivalent in plain JS but I don't think we have too many of these lines either.

The best way to start is to start from the outside in, rewrite the small piece first (plugins, controls, ...) and then go into the core one as the final piece. If @Danielku15 code is all working, I can start with rewriting some of them, but I don't want to start if it's not ready to start

[Danielku15]

For replacing such libraries like jQuery in a big fashion, I made in the past good experience with just developing an own library with the same operations, and then use IDE "inline method" or refactoring features. This way you can advance step-by-step on replacing certain method calls while still having some jQuery parts within your "wrapper".

For the this scoping with lambdas using directly the TypeScript compiler API would be my choice of analysis engine. Like a custom linter for this purpose. Most places are already covered by TypeScript itself because it knows where this points to and what members it has. But places like the following one are tricky because when the method is called, this will not point to the Grid instance anymore within the method:

https://github.com/Danielku15/SlickGrid/blob/8ab341690b64527e90463cd24c86e3ff4d552cdd/src/slick/Grid.ts#L720

This would need to become:

this.selectionModel.onSelectedRangesChanged.subscribe(this.handleSelectedRangesChanged.bind(this));
// or 
this.selectionModel.onSelectedRangesChanged.subscribe((e,ranges) => this.handleSelectedRangesChanged(e, ranges));

Most places are easy to find because they are at the same places (jQuery.on, subscribe etc.)

[ghiscoding]

I corrected your typo, it should .bind(this) not ,bind(this) and yes I use that a lot in my SlickGrid wrapper libs, I'm more concerned about what I wrote in my previous post but yes I agree that we could maybe write a wrapper that even if the DOM element is not found we would still return an object, easier to go step by step as you said.

[JacobMGEvans]

Greetings,
Not sure where the progress is on this migration, however, If you are interested we can "Raid" your repository, there would be one big PR from our Organization, for a large specific task/problem domain; in this case TS conversion.

We would need a maintainer as a point of contact, we prefer using Discord https://discord.gg/xkdkAJZsBR

Let me know if you are interested.
You can read more about what we are doing here: https://github.com/OpenSourceRaidGuild/tutorial-quest
This is also an example of how we work and the workflow: HospitalRun/hospitalrun-frontend#2516

cc: @nobrayner @mpeyper @Aprillion

[6pac]

I hasten to add, I've seen a lot of trends come and go, so I tend to be a really late adopter, only when I think something is actually going to stick around for more than a few years. I have to say I am not completely convinced that TypeScript isn't the latest trend that will disappear in a few years (noting also it's developed by M$, the king of poorly conceived and short lived ideas in the tech space).
And I've previously experienced huge problems with frameworks that have similar philosophies to React once the pages get too complex. They are great for simple stuff. So I actually actively avoid that.

So don't want to dampen anyone's enthusiasm, I just feel like I should explain why I have have reservations and have been slow to take up new developments. It's not that I don't like new stuff, but I've been burnt soooo many time before.

[ghiscoding]

@6pac I have been coding all my libs with TypeScript, which as you know are wrapper on top of your repo and all I see is benefit, I catch a lot of bugs early in the process, that is also the biggest I've pushed so many fixes in your repo for the past 3 years. We also get intellisense out of the box with TypeScript and the language keeps growing in adoption every year (every framework and I really every framework, are now written in TypeScript), TypeScript is top 5 in most used languages and asked questions on Stack Overflow, so I don't see it going anywhere anytime soon. Adding Typing to a project is just making it so much more easy to catch bug early before shipping to production, can you imagine coding C# without types? Since you know .Net, I assume C#, it is very very similar (it is made by the same company) and you see it in the language, there's ton of available for example some starters on MS website here and even better some youtube learning video, like this guy he's really good at teaching, check this video. Going to TypeScript would also benefit in importing the lib, I just see benefit at the end of the day, don't let this scare you, it's quite easy for a .Net developer to get started with TypeScript, the only real difference is the types are on the right in TypeScript while being on the left in C# and that's about it, the rest is nearly the same (again because it's the same guys who created C# that created TypeScript) and it's built-in in VSCode. Hope that helps.

I really suggest you to watch that youtube video and after watching the hour video, I'm sure you'll understand why I'm pushing for the change

[6pac]

Thanks @ghiscoding, it's not at all that I'm worried about it, I'm sure I can learn it in a flash if I want to. Strongly typed languages have been my bread and butter for two decades. But personally it's not typing, or lack of it, that's important, it's the language design, and I think JS is extrememly well designed. JS is related more to LISP, the ancient machine learning language, than C. It's specifically designed for flexibility and the ability to 'meta' up. It can do a bunch of stuff that would be wildly difficult in C# just because of its different typing system. I'm just not at all convinced that strong typing actually belongs in JS, although I am aware that you can type as 'Any' in TS if you don't want strong typing.

Just for the record, I'd observe that .NET was stolen more or less flagrantly from Sun (Java) - the reason it's good is specifically because it wasn't designed by Microsoft. and I suspect MS hired the entire team from Sun for further development - and Java was designed by some of the best developers in the world.
Not that I'm hating on MS on principle, I have nothing against them, other than that they consistently keep dishing up deeply flawed and poorly thought through products. I've been using their products professionally since 1992, because you can't not if you're a business developer.

HOWEVER, clearly everyone wants to do this, so I'm not going to hold it back. It's time for me to embrace TypeScript.
I just feel that I have to state my position.

To clarify what I'm asking, I'm sure TypeScript will be a piece of cake, I'm more concerned about learning NodeJs, because it's all about packaging and module management rather than language per se.
Are you aware of any good tutorials around that? I'm sure there are 1000's of resources out there, it's just that finding really good ones can take time, something I don't have a lot of.

[ghiscoding]

Just to be clear, TypeScript is a superset of JavaScript, the output of TypeScript build is JavaScript, we just need to specify which browser or EcmaScript version we want to target, in our case we'll target ES5 so it still works in legacy browser and again that would be ES5 JavaScript which is what the browser will use, TypeScript is only used when coding and running the build and it's not used in the browser, when it runs the build, it removes all the Types, Interfaces, etc... only to be left with JavaScript.

As for NodeJS, it's only used to run the TypeScript build, nothing else (or maybe not even needed if you use VSCode to build, I'm not fully sure)

[6pac]

OK, I think I'm relatively across typescript now. It's better than I thought it would be - less prescriptive. In particular, getting intellisense will be a major bonus, it's been a long wait for that.
I have friends who have told me that Microsoft is actually changing its culture recently - perhaps it's true!

Re NodeJs, I'm aware that it's completely unrelated to Typescript. It's just something that I need to learn at some point in order to be across modern js packaging and delivery, and it may as well be now. Don't worry about it, I'll dive in shortly.

[ghiscoding]

this is now done, so I can close this Discussion :)