Replace runtime imports with static imports

[alexanderroidl]

Currently there are dynamic imports at runtime requiring programmatically reading the file system and performing asynchronous operations, which can be avoided by indexing all desired files in an index.js and statically importing that file instead.

[alexanderroidl]

@orangecoding Unrelated to this but apparently due to the new workflow ESLint warnings now show up below GitHub's change overview 😊 Kind of cool even if unintended👍

[orangecoding]

@orangecoding Unrelated to this but apparently due to the new workflow ESLint warnings now show up below GitHub's change overview 😊 Kind of cool even if unintended👍

Yep, got a notification about that a couple of weeks back.

[alexanderroidl]

@orangecoding Unrelated to this but apparently due to the new workflow ESLint warnings now show up below GitHub's change overview 😊 Kind of cool even if unintended

Yep, got a notification about that a couple of weeks back.

I think it's new actually, on my MR four days ago it wasn't there: https://github.com/orangecoding/fredy/pull/142/files

[orangecoding]

I know I know, this makes things more performant.. BUT, that comes with a price. The reason I did it the way it is today is because ease of use. You can simply add a new file, throw it into the folder and you can be sure it will be read and it is available. You do not need to register it somewhere. This ease of use of course comes with the price of a little bit of performance, but since Fredy is not rly a high performant app, I'm willing to pay the price.

What's your take on this?

[alexanderroidl]

While I understand how there is convenience to importing the files like so I would avoid it here because it requires us implementing loading logic ourselves to a certain degree while all functionality we need is already available natively.

I would avoid implementing anything around runtime-loading application parts, as it's not necessary for the project, we have a set number of providers and adapters. They don't change during runtime, plus there is an existing system for indexing them in directories.

What we have here is a cool idea but highly uncommon and desirable to avoid IMO

[orangecoding]

I totally get your point and usually would agree though I still think for this very case, I don't see a real reason of changing this to a way that makes it more complicated for those trying to implement provider. Again I fully see your point and in an app that is resource-critical, I would never do it this way, but for Fredy, I still think this is better.

[alexanderroidl]

Regardless of performance I don't think our case justifies a custom loading implementation. I would expect anybody implementing a provider capable of adding to the index too and it not being too much of an extra effort

But other than that, I would like for providers and notif. adapters to use their own directory and multiple files. That would mean we would have to further complicate our logic to support this :/ What do you think?

[orangecoding]

What is the benefit of having their own folder? Mostly structurally 'cleanup' (less cluttered)?

[orangecoding]

@alexanderroidl I'd close this pr as I don't see any activity. Thanks a lot tho