With this PR, EventData and methods for adding/removing listeners will now be generic:

// This event is inherited from View, so eventData.object is// inferred to be a View.newButton().on("loaded",(eventData)=>{eventData.object;// TypeScript infers this to be a View});// You can, however, explicitly pass the generic to narrow// that down to Button:newButton().on<Button>("loaded",(eventData)=>{eventData.object;// TypeScript infers this to be a Button});// Button-specific events don't require passing the generic:newButton().on("tap",(eventData)=>{eventData.object;// TypeScript infers this to be a Button});

Please do give comment on the discussion points I've posted and (once we've reviewed it and prepared a build of it) a try on your projects, as I fully expect it'll result in some TypeScript grumbles.

PR Checklist

• The PR title follows ourguidelines - TODO: I'm keeping them as individual commits for review, but we can rename upon squash.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed theCLA.
• All existing tests are passing:https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#running-unit-tests-application.
• Tests for the changes areincluded - It's largely a typings change, so no new tests to add.

What is the current behavior?

Types for EventData and adding/removing listeners are non-generic, so we always have to writeeventData.object as Button if we want anything more specific than an Observable.

What is the new behavior?

Improved inference in most cases. The events in Application have always beenvery messy though, so I've left those as defaulting to Observable even though some could be narrowed to View, as I simply can't get my head round them.

Note that this PR would introduce breaking changes for library authors. As although we do provide default args for each generic, if they've extendedon anywhere, they'll have to add the generic, as demonstrated in thisplayground:

For discussion

What should the generics be?

The generics implemented in this PR are "better than nothing", but still not ideal. See what I ideally wanted to implement vs. what I was able to get working:

// What I wanted:exportabstractclassViewextendsViewCommon{on<TextendsView= this>(event:'loaded',callback:(args:EventData<T>)=>void,thisArg?:any);}// The only thing I could get to work:exportabstractclassViewextendsViewCommon{on<TextendsObservable=View>(event:'loaded',callback:(args:EventData<T>)=>void,thisArg?:any);}

The former is more strictly correct, but I just couldn't get TypeScript to accept it 🤷

Should we narrow the default generic for EventData in the first place?

Although I think itis correct for the methods for adding/removing event listeners to have more narrow generic defaults than justObservable, e.g.:

exportclassSegmentedBarextendsViewimplementsAddChildFromBuilder,AddArrayFromBuilder{on<TextendsObservable=SegmentedBar>(event:'selectedIndexChanged',callback:(args:SelectedIndexChangedEventData<T>)=>void,thisArg?:any):void;}

... I am unsure about whether the EventData interfaces should behave the same:

// Would we prefer a narrow default?exportinterfaceSelectedIndexChangedEventData<TextendsObservable=SegmentedBar>extendsEventData<T>{oldIndex:number;newIndex:number;}// ... or just stick to Observable?exportinterfaceSelectedIndexChangedEventData<TextendsObservable=Observable>extendsEventData<T>{oldIndex:number;newIndex:number;}

Mainly because we don't know whether others might repurpose the same event (SelectedIndexChangedEvent can be used for more than just SegmentedBar, and indeed there are duplicates of this interface across the codebase). Of course consumers can just specify the generic explicitly if they want to override the assumed default of SegmentedBar, so it's not the end of the world whichever choice we go with.