[BUG] Type signature for stopTrackEvent is incorrect

[GravlLift]

Description/Screenshot
The properties parameter is of type {[key: string]: string}

ApplicationInsights-JS/shared/AppInsightsCommon/src/Interfaces/IAppInsights.ts

Line 28 in ed8632a

stopTrackEvent(name: string, properties?: {[key: string]: string}, measurements?: {[key: string]: number}): void;

Per the README.md, "objects are okay too".

ApplicationInsights-JS/README.md

Lines 270 to 284 in ed8632a

	When using stopTrackPage and stopTrackEvent, you can pass in data categorized by types:
	Strings: These should be included under the properties field.
	Numbers: Add these under the measurements field.
	Remember, the order of the properties and measurements should not be altered. You can achieve this using the following code structure:
	```js
	appInsights.startTrackEvent("event name");
	appInsights.stopTrackEvent("event name", {
	stringProp1: 'string',
	stringProp2: {nested:"objects are okay too"}
	},
	{numProp1: 3.15, numProp2: 90000}
	)
	```

Expected behavior
Testing reveals that nested objects are handled just fine here. Perhaps the signature should be updated to match trackEvent's customProperties parameter of type {[key: string]: any}?

Additional context
All links and testing in version 3.3.3

[siyuniu-ms]

Thanks for bringing this up!

Currently, the stopTrackEvent method is defined to accept properties of type {[key: string]: string}. When you pass a nested object to this parameter, it gets automatically converted to a string and is then sent to the Azure portal as a string.

This means that if you call stopTrackEvent with a nested object during runtime, for example, from the browser console, the request will still go through successfully. However, if you use this in your code and attempt to build it, TypeScript will throw an error because the method expects only string values for properties.

@MSNev: Should we enforce the properties field to only accept strings, or should we consider allowing more flexible types? While the current implementation works with nested objects at runtime, this behavior can be confusing for users who encounter TypeScript errors during development.

For more details, please refer to the related issue and pull request:

Issue: ApplicationInsights-JS/issues/2209
Pull Request: ApplicationInsights-JS/pull/2270

[siyuniu-ms]

fixed in #2450