refactor: migrate provider base to ES6 class - #9
Conversation
Replace legacy `Class.extend` in hktransportetaprovider.js with a native ES6 class while keeping `register/initialize` behavior compatible.
|
Thanks. But I just have one tiny question (not related to this PR). Do you know why |
|
Good question. 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
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.
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. |
|
Thanks for the explanation. That makes sense. |
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
Classis removed in an upcoming MagicMirror release.