ui5-typescript icon indicating copy to clipboard operation
ui5-typescript copied to clipboard

Can generics be added to methods that return types that are extended or any?

Open lordheart opened this issue 2 years ago • 1 comments

For instance the method byId on

  • "sap/ui/core/mvc/Controller"
  • "sap/ui/core/mvc/View"
  • "sap/ui/core/UIComponent"

Etc. all return UI5Element, but this usually means that accessing say the SetEnabled method on a sap/m/Select throws a typescript error that the method is not found.

const selectElement = this.getView().byId(anIDforASelectElement);
selectElement.setEnabled(enabled); // error here

If the byId method was generic it could be called like this

const selectElement = this.getView().byId<Select>(anIDforASelectElement);
selectElement.setEnabled(enabled); 

Like that type completion would then work and no errors would be thrown.

The generic declaration can even be added in a manner that makes it optional to add the generic type for current code using the types returned UI5Element.

The current definition byId(sId: string ): UI5Element; would just need to be changed to byId<T extends UI5Element = UI5Element>(sId: string): T;

Would this be possible and wanted or is casting (using as Select) the preferred approach? If not then possibly the returns of type any could be changed to unknown to force a typecheck.

I extended "sap/ui/base/Event" in a similiar manner to allow myself to pass in the Parameter types so that event.getParameter also has type completion. But I need to learn more about how events work to figure out how many generic parameters I would need to have all it's methods return typed objects instead of any.

Edit: this is using the sap/ui5-types-esm

lordheart avatar May 19 '22 06:05 lordheart

This was already discussed in #16 and also in one of our Sample Apps (https://github.com/SAP-samples/ui5-cap-event-app/pull/5#issuecomment-855343402).

Microsoft's own dtslint rules recommend not to use generics like this (they call it "disguised type assertion"). That's one of the reasons why we did not yet invest here (e.g. the tool chain issues mentioned in #16 still exist).

codeworrior avatar May 19 '22 07:05 codeworrior