Decoupling logic from the ui

[szsascha]

Code for IBM i is getting bigger and bigger. It's becoming increasingly difficult to find the right places in the code. Maybe now would be the right time to rethink the current code structure and do a refactoring before adding more stuff.

There are many functions which are not directly depending on the ui. For example the whole IFS handling for down- and uploading files or much more in this direction.

A possible solution could be to take a big part of the logic out of the extension and create a new library out of it. The extension will use this library. But it will bring a bit more structure to the codebase and the library can be also used by other projects.

What's your opinion on this?

[worksofliam]

You're not wrong, the extension is getting very big. I'd be curious to how this separate library might look - that's a lot of work in itself.

Of course, like you, have a day job. Finding the time to do all this work is not simple, esp. considering we have a few PRs in the works too.

Of course, I am totally open to PRs of any refactorings.

[worksofliam]

@priceaj I am open to the idea.

Curious to how big your PR will be. We'll likely need to do a bunch of testing to make sure things continue to work (including our deployment)

[priceaj]

@worksofliam Okay so I've done some preliminary testing here https://github.com/priceaj/vscode-ibmi/tree/Typescript

I've moved from npm to Yarn, and added the typescript stuff in, you should basically be able to convert the js file to .ts and it should just work and get the benefit of the strong typing (imagine RPG where type errors are caught by the compiler, not during execution!)

However I've had a few problems converting some of the files mainly because the code needs some work.

There is also no way I can ever get this merged in at present because it would require renaming every js file which would conflict with every PR.

What we could do is adopt a progressive strategy, e.g. put the TS infrastructure in place then migrate to TS as we go along by just renaming the file and fixing any type issues that come up

[szsascha]

@priceaj

Sounds great!

Why the move from npm to Yarn?
(Just asking because I didn't know the exact advantages. Never used it before.)

[priceaj]

It will ensure consistency between machines because it stores versions and it caches packages... But I mainly use it because it's faster because it does things like parallel package downloads and installs!

[worksofliam]

What we could do is adopt a progressive strategy, e.g. put the TS infrastructure in place then migrate to TS as we go along by just renaming the file and fixing any type issues that come up

@priceaj I think this is the best option for the time being. It's likely the best thing to do, then any future PRs will require the change to TS.