Improve maintainability of services

[AlvaroBrey]

To improve the maintainability of the project going forward, I would suggest:

• Defining each service in a separate file, or
• Defining each service in a folder, with a separate file for the injected JS

Currently editing services is quite a pain in the ass, especially if you have to touch the unformatted, all-in-one-line injected JS. I don't know how complex of a modification this would be.

[TheGoddessInari]

Already been looking into it since the beginning of the fork.

The problem is that if things are injected 'beautified', the interpreter takes a lot longer to parse stuff in. This can be from 30-90% longer, depending on the amount of whitespace that has to be parsed. Perhaps that's just worth it, or perhaps the optimizer step would crunch that as well.

I'll look into it today.

[AlvaroBrey]

Another option would be de-beautifying the code at runtime but before injection, I guess.

[TheGoddessInari]

At runtime would probably end up slower than simply interpreting the code.

I realized there's a problem, though, I think. I don't think javascript/node provides a way to include a file as a "string literal", like how C's #include works, so even though the point would be to have beautified source files for this, there's no way to statically include them into a string (as it is own), and dynamic wouldn't work with ExtJS.

My workflow is basically to put a uglified string into VSCode, beautify it, work on it, re-minify it, except now I just keep the beautified files around. That workflow wouldn't work very well with the git repo, and trying to maintain the functions as an exported string so require() would work, would also keep beautifiers, linters from working on the actual code. I've checked a fair bit, and I'm not seeing any sane way to do this, because in Javascript, there's no guaranteed "compile phase", and hence no way to statically import a file as a string.

Perhaps there's a way in TypeScript to do this? It'd still require getting rid of ExtJS first, but if TS can do this in the compilation phase, it'd be feasible at that point.

[AlvaroBrey]

I realized there's a problem, though, I think. I don't think javascript/node provides a way to include a file as a "string literal", like how C's #include works, so even though the point would be to have beautified source files for this, there's no way to statically include them into a string (as it is own), and dynamic wouldn't work with ExtJS.

I found raw-loader which is similar to what we want. Edit: currently trying to make it work with ExtJS, let's see how that goes. Still trying to figure out what to do with the whitespace though.

Edit2: I give up for now, this is way harder than it should y.y

[AlvaroBrey]

There's another option that hadn't occurred to me yet: we may want to generate the ServicesList.js file with a custom script at compile time. This hypothetical script would read metadata files from a established path, and generate the service list. It could include a de-beautifying step and use multiple files per service (so as to keep the JS separated from the metadata).

Pros:

• Allows us to define service metadata in whichever format we prefer, which includes separating into multiple files

Cons:

• Would mean another step on the compilation chain
• Need to actually write the script

Does this seem reasonable, @TheGoddessInari ? If so, I may give it a shot this weekend.

[pigsflew]

This seems to me the best way. Especially cool if you created a folder structure to gather the pieces together, eg:

services/{id}/
services/{id}/logo.{ext}
services/{id}/service.js
services/{id}/unread.js

service.js would contain:

{
	name: "My super cool app"
	,url: 'https://example.com'
	,type: 'messaging'
	,titleBlink: true
	,description: "The best app in the world's example description"
	,note: "Be careful with this one, it's super cool."
}

unread.js would be the prettified version of the js_unread.

build would construct the ServiceList.js from this by minifying the unread.js and placing it into the service.js as js_unread, setting "logo" to "services/{id}.{logo_ext}" and copying the logo file into the build directory's resources/icons/services directory that way.

[TheGoddessInari]

I've tried messing around with this a bit, still not sure how we'd get ExtJS/closure to evaluate and insert the file(s) at compile time.

If someone manages to get a lead on that, I'd be happy to split the files out as needed for organization and sanity purposes.

[AlvaroBrey]

Well, I actually meant writing a script that would generate a ServicesList similar to the one we have right now, and just having npm execute that script as the first step of the compile script. There would be no need to change anything related to ExtJS because it wouldn't know anything had changed.

[vraravam]

This is similar to how Ferdi does it: there's a compile/package-time shell command that's run, which generates some files, and those files are then packaged into the installable file. The similarity ends there - since the files in question are zipped, etc and the runtime process takes case of unzipping, reading contents and injecting into the electron process as needed.

For Hamsket's usecase, I would think that generating ServiceList.js in the expected location would be sufficient and the current runtime processing could continue (with the only changes being in the git repo and the compile/package-time delta.