MrOtherGuy / fx-autoconfig

Load custom javascript in browser context
Mozilla Public License 2.0
173 stars 11 forks source link

Experiment with file-based Config usable by loader and scripts #37

Open MrOtherGuy opened 1 year ago

MrOtherGuy commented 1 year ago

I don't know how or if this is good idea, but let's describe it anyway.

So, going through all the files in the JS and CSS directories seems kinda stupid. I played with an idea where I would create a configuration file with specific name - for example fx-autoconfig.ini and the loader would parse it and then load scripts and styles based on that.

Currently I'm testing an .ini file based method. Goes like this:

[Loader]
key1=test
key2 = some other

[Styles]
author_style.uc.css = true
agent_style.uc.css = false

[Scripts]
000_test_runner.sys.mjs     = true
legacy_tests.uc.js          = false
test_manifest.uc.js         = true
test_mjs.uc.mjs             = true
test_module_script.sys.mjs  = true
test_module_script.uc.js    = true
utils_tests.uc.js           = true
write_to_shared.uc.js       = true
x_disabled_script.uc.js     = false

[Area]
somekey = 2

[000_test_runner.sys.mjs]
somekey = 3

This would result a javascript object like this:

{
  "Loader": {
    "key1": "test",
    "key2": "some other"
  },
  "Styles": {
    "author_style.uc.css": true,
    "agent_style.uc.css": false
  },
  "Scripts": {
    "000_test_runner.sys.mjs": {
      "somekey": 3,
      "enabled": true
    },
    "legacy_tests.uc.js": false
    "test_manifest.uc.js": true
    "test_mjs.uc.mjs": true
    "test_module_script.sys.mjs": true
    "test_module_script.uc.js": true
    "utils_tests.uc.js": true
    "write_to_shared.uc.js": true
    "x_disabled_script.uc.js": false
  },
  "Area": {
    "somekey": 2
  }
}

(Except that Loader,Styles, Scripts and Area are actually Map objects.)

If the config parser finds an ini section with a same name as one of the keys inside a section, then the config parser uses the section as the value of that key. But in such case it uses the "original" value of the key as value of "enabled" key in the resulting map (unless the copied section also has an "enabled" key).

The loader itself treats keys in Scripts and Styles Maps that are true or false meaning as if that script is enabled or not.

And now, the loader would only try to look for files that are declared in this config file. It will then try to run scripts that are enabled in the config.

Scripts could then use this as well, they could either parse their required files themselves (exposed through utils) or by asking the loader to give their back the config it has already read at startup.

aminomancer commented 1 year ago

Would scripts be added to the ini file automatically, or user has to add them? Seems maybe kind of tedious if you have a lot of stuff.

I guess you could add a prompt to ask the user what they wanna do with new scripts/stylesheets.

MrOtherGuy commented 1 year ago

Interesting idea, yes we could do that since there is already code to show notification bar on first run.

But yeah, if the config mode is used then new scripts would need to be declared in the file and not be picked up automatically.

At this point this is just an idea though, not necessarily something that would be added, at least not necessarily in the form described above.

The main motivation here I think is that it feels wrong to me to scan files on startup and maybe "declaring them" would be better.