Make component constructor arguments explicit

[jacobq]

With classic components, it was my understanding that the arguments to init / the constructor were private API and that is why they were to be opaquely passed thru using ...arguments. However, the public API for glimmer components specifies that it takes exactly 2: owner and args, so it seems like it would be better to make this explicit. This also helps avoid errors/warnings when using TypeScript.

[RobbieTheWagner]

I feel like ...arguments is nice because you could be extending a class that takes more arbitrary parameters.

[jacobq]

I feel like ...arguments is nice because you could be extending a class that takes more arbitrary parameters.

There is certainly a time and place for arguments. There are several reasons why I think it would be preferable to list the parameters explicitly in this case (glimmer components) though:

1. Those familiar with JavaScript will have no trouble converting code that uses a named list of arguments to a more compact form that uses arguments, if they want to. However, the same cannot be said for the other way around. In that case, one needs to do some digging in the API docs to see what the arguments actually are. I do not think that hiding this information is doing any favors to those learning from these examples.

2. The arguments for glimmer components are public API and therefore stable, so one need not worry about future versions suddenly introducing an additional argument or something like that. In previous versions of Ember a number of developers (myself included) got into the habit of writing this._super(...arguments); whenever extending built-in methods whether it was needed (e.g. init) or not (e.g. didInsertElement) simply out of ignorance and fear that something might break without it (e.g. assumed we were treading on the boundaries of private APIs). One of my favorite things about recent versions of Ember has been that it is becoming "less magical" (e.g. native classes, no need to extend EmberObject for most things, no need to remember to use .get and .set, @tracked making it much easier to avoid bugs due to forgetting to include a dependent key in a computed property definition, etc.), and I think that using the named arguments from the spec rather than hiding them behind arguments aligns with that direction.

3. People developing with TypeScript (e.g. using ember-cli-typescript) will encounter an error like TS2556: Expected 2 arguments, but got 0 or more. when using super(...arguments) in these components. While, admittedly, it's not the responsibility of the core Ember.js community to support this subset of users, TS errors can serve as a warning sign of potential bugs, and it's advisable to avoid writing code that would generate them when simple alternatives exist.

[pzuraq]

Agreed with this general approach, this is what we’ve been doing in general for the reasons outlined by @jacobq