Instead of requiring the user to assert what type the object is for the event, the typings could help out.
With typings as they are now
// ui/action-bar/action-bar.d.ts
type ActionItemAttributes = ViewBaseAttributes & {
// ...
onTap?: (args: EventData) => void;
// ...
};
function onTap(args: EventData){
const icon = (args.object as ActionItem).icon;
}
Potential improvement
// We could extend EventData (like this) or generate an identical interface.
interface NarrowedEventData <T extends Observable = Observable> extends EventData {
object: T;
}
// ui/action-bar/action-bar.d.ts
type ActionItemAttributes<T extends ActionItem = ActionItem> = ViewBaseAttributes<T> & {
// ...
onTap?: (args: NarrowedEventData<T>) => void;
// ...
};
function onTap(args: NarrowedEventData<ActionItem>){
const icon = args.object.icon;
}
Disadvantages
The user would only get the inference if they were writing the event handler function inline in the JSX. If they're writing the event handler function elsewhere, then yes, they'd be typing out as much to specify the function parameter as they'd have to when specifying the type assertion anyway.
NarrowedEventData is simply more to type than EventData (we could overcome this by lobbying NativeScript Core to change EventData to be generic in the first place).
Advantages
Improves the developer experience for every single usage of every event handler in their apps.
object: any; is a poor representation of what object's typing is in the first place.
Instead of requiring the user to assert what type the object is for the event, the typings could help out.
With typings as they are now
Potential improvement
Disadvantages
NarrowedEventData
is simply more to type thanEventData
(we could overcome this by lobbying NativeScript Core to change EventData to be generic in the first place).Advantages
object: any;
is a poor representation of whatobject
's typing is in the first place.