Open lordheart opened 2 years ago
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).
For instance the method
byId
onEtc. all return
UI5Element
, but this usually means that accessing say theSetEnabled
method on asap/m/Select
throws a typescript error that the method is not found.If the
byId
method was generic it could be called like thisLike 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 tobyId<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 typeany
could be changed tounknown
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