Skip to content

refactor: migrate provider base to ES6 class - #9

Merged
winstonma merged 1 commit into
winstonma:mainfrom
KristjanESPERANTO:es6
Jun 5, 2026
Merged

refactor: migrate provider base to ES6 class#9
winstonma merged 1 commit into
winstonma:mainfrom
KristjanESPERANTO:es6

Conversation

@KristjanESPERANTO

Copy link
Copy Markdown
Contributor

This removes legacy inheritance usage while keeping the existing provider API (register/initialize) behavior compatible, so current provider files continue to work unchanged.

Also future-proofs the module in case Class is removed in an upcoming MagicMirror release.

Replace legacy `Class.extend` in hktransportetaprovider.js with a native ES6 class while keeping `register/initialize` behavior compatible.
@winstonma

Copy link
Copy Markdown
Owner

Thanks. But I just have one tiny question (not related to this PR).

Do you know why performWebRequest was removed but not keep as a helper function. If that's the code all the downstream module would not need to make changes. I think it would be a surprise if the downstream module suddenly won't work.

@KristjanESPERANTO

Copy link
Copy Markdown
Contributor Author

Good question. performWebRequest was removed in #4032 as part of the migration to server-side fetching via HTTPFetcher. Keeping it as a client-side shim wouldn't have made sense since the whole architecture shifted - fetching now happens in the node helper, not in the browser. And only 3 3rd-party modules used performWebRequest.

Is there a specific case you have in mind?

@winstonma

Copy link
Copy Markdown
Owner

Is there a specific case you have in mind?

No I am just curious because removing an API could break downstream modules. So I would keep the API and do the implementation inside the performWebRequest function just to avoid breaking things.

And only 3 3rd-party modules used performWebRequest

How can I find out this?

@KristjanESPERANTO

Copy link
Copy Markdown
Contributor Author

How can I find out this?

By cloning all 1400+ modules and then search through them.

Since I'm working on the module list page I'm already have all modules cloned.

... just to avoid breaking things

Of course, we try to avoid breaking changes, but if only one-tenth of one percent of the modules uses a function that can be replaced with something more modern, the decision isn't a difficult one. We now put more effort on security, and to make progress there, we need to reevaluate some of the old patterns. That creates friction, but I try to keep it to a minimum. Part of that is by creating PRs like this one.

@winstonma

Copy link
Copy Markdown
Owner

Thanks for the explanation. That makes sense.

@winstonma
winstonma merged commit 34cd5dc into winstonma:main Jun 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants