Taking over TS port of Sparnatural

[SteinerPascal]

I would like to discuss with you if you are interested in taking over my TS port of Sparnatural? I'm not finished yet but I think you will like the endresult. I have not just ported it, but refactored already quite a bit. I think it makes more sense to put together our efforts instead of splitting it and doing the same work.

My suggestion would be the following: Don't fix and implement for the moment new stuff on Sparnatural. If i have questions about unused or weird code behavior and you have an idea how to fix it, then just let me know and I can implement it. When I'm finished (hopefully within the next week) you can take over the TS port and we can team up to let Sparnatural thrive. What do you think? does that sound to your liking?

Or maybe you have a better idea?

Btw: the current status is here: https://github.com/SteinerPascal/sparnatural-port

[tfrancart]

That's exciting, but also potentially risky, so I need to think about it. I am not familiar with typescript, so 2 dummy questions:

• which IDE can I use to edit typescript ? what do you use ?
• are there any impact on the webpack config ?

Can you give me 2 or 3 pointers to the parts of the code you have most refactored ?

This is risky because I need to make sure that I and my team can continue maintaining Sparnatural in the future, we have clients for which we develop new features.

Thanks for the great contribution.

[SteinerPascal]

Hi! Sure I understand and your concerns are totally reasonable. Let me explain what I did, why I did and how this affects the project. But first of all, answering your 2 questions:

1. VSCode is a very good fit for TS and I exclusively use it to work with TS. But I'm sure you could also use lime, atom or others. If you have never worked with TS i would suggest you look at some tutorials. It is very easy to use since it is a superset of JS. That means every valid JS is also a valid TS. TS just adds OOP.
2. Yes indeed there is some impact on the webpack config. check out these lines: https://github.com/SteinerPascal/sparnatural-port/blob/e51b51ad75fec5c9d630b54f47c9d30c52746034/webpack.config.js#L33-L37 That was the only change necessary(and of course the npm dependency) to the webpack config so it would bundle all the .ts files and throw them into the sparnatural.js

Now to the rest. I think I refactored 70% of all the code so there are many (I added roughly 40'000 insertions of code and deleted roughly 250'000 insertions without taking away any functionality) small and medium changes included. But if you go through the code you will still recognize it. Let me highlight a few major changes:

1. Changing the GroupContainere hierarchy and make it OOP style. The class GroupContainere is now gone since it didn't add any value to the code. That also includes refactoring all the "classes" in sparnatural.js and making them their own components.
2. Sparnatural and Yasgui are now proper custom htmlelements. They are now intialized like this: https://github.com/SteinerPascal/sparnatural-port/blob/e51b51ad75fec5c9d630b54f47c9d30c52746034/src/index.html#L41 Also look in general at the index.html. It is now way cleaner.
3. A lot of changes to make the Components more "independent". Meaning no component should interfere with the other components html. Cleaning a lot of unused code.
4. Introducing Interfaces like this: https://github.com/SteinerPascal/sparnatural-port/blob/e51b51ad75fec5c9d630b54f47c9d30c52746034/src/sparnatural/spec-providers/ISpecProviders.ts#L4 So you have some structure and safety for code extensions
5. Outsourcing a lot of code into private functions like this: https://github.com/SteinerPascal/sparnatural-port/blob/e51b51ad75fec5c9d630b54f47c9d30c52746034/src/sparnatural/ts-components/htmlcomponents/startendclassgroup/EndClassGroup.ts#L167 This enhances readability and increases the code semantic.

I'm not sure with what, if any, other languages you are familiar with but since TS introduces "static" typing it comes with all the advantages of static types (better inellisense, null checks, typechecks, generics, interfaces,encapsulation, way less runtime errors and more...). If you don't know about it just google for some comparison of JS and TS. I'm sure that will be convincing. Additionally, I would suggest you have a look at TS anyway since already quite a lot of frontend code is only written in TS (see angular). Refactored code will make this project more attractable to the open source community which can increase contributions.

Okay that should be enough for the first part =) Please ask more questions if you have any. I would also suggest to have a call, so I can explain and show more of it. What do you think?

EDIT: Sorry, I only spoke about the advantages of TS and as with every technology there are also disadvantages:

1. You have to learn TS. So there is a bit of a learning curve.
2. Static Types can "annoy" sometimes, since it forces the coder to write better and safer code.
3. TS code has to be first transpiled and bundled into JS code since the browser doesn't understand TS. But you have done that already with webpack.
4. TS although introducing static types can be used quite flexible (for example the any type) which could lead to a wrong safety. (like: the coder thinking everything will work 100% once the code is transpiled)

[tfrancart]

@SteinerPascal Thanks for the detailed answer, and the tremendous refactoring. I have been doing Java JEE for 20 years, so I am a big fan of static typing ;-) @antoine37120 on the contrary is a pure Javascript guy :-) I would certainly be interested to meet and talk to you, and most probably we could take over the refactored code directly in Sparnatural, after testing. Why don't you drop me a message with your email in the contact form at http://www.sparna.fr/contact/ and we continue the discussion privately ? Friday 13 could be a good time to meet for both me and @antoine37120

[tfrancart]

@SteinerPascal Additional comment : to ease the migration path and testing phase, do you think it would be possible to use the code ported to TS without changing anything to the way Sparnatural is inserted / initialized in webpages ? so that we could simply replace the Sparnatural code in existing deployments, and test the behavior ? and then in a second phase we could change/clean/enhance the way it is initialized.

[SteinerPascal]

Hi let me answer to the two comments: 1. Cool! Yes, I will drop you an email. But certainly the 13th is too early. I'm now refactoring nearly everything. So far i only haven't touched the SparqlQuery generation files. But that means i need a bit more time as anticipated to bring it up and running again. Most likely I will also miss one or two minor UI features (probably lost it somewhere on the way). So, I think you will then tell me these and i can fix it. But so far i can tell you a couple of highlights in the new Code (or at least goals):

• No more global functions, variables and so forth. Only Events
• Almost everything is now a Component (like in React.js)
• Rendering of a component is now purely a responsibility of that component. No more interComponent registering of eventhandlers, setting html classes or anything.
• Properties only flow from parent to child component (like in React.js). If information flows up, it's in form of an event.
• No more JQuery.find() methods
• JQuery is only used to render the html to pages. So a possibly rewrite in React will be very easy. React will just take over the rendering
• splitting of the css into the 7-1 pattern
• Structure of the html component "groupe" is now a binary tree. This allows for nice recursive traversing and traversing in different orders if that should come in handy in the future.
• Since all the actions, statehandling etc. happens now purely in TS, it would be possible to think about automated testing.

Hmmm I'm not sure I understand why that should matter that much? I think you only need to take over the configuration and adapt a little on the html, but then again i don't know how you deployed it. Maybe I'm missing something? However, I think it still needs a lot of work till I'm ready for the handover. Let's talk about it later.

[SteinerPascal]

small update: I think this is what i want to achieve in the end. Can be used with React, Angular, normal web pages.

[tfrancart]

This is very fine and I think it would be great to move toward a WebComponent. I just want to ease the migration path and lower the risk of the port to TS, this is why I was thinking if it was possible to have a step where we can do a drop-in replacement of the code in existing deployments, test if everything is fine, and then as a second phase do backward-incompatible changes that would require existing deployments to be changes.