[BUG] Type signature for stopTrackEvent is incorrect
Description/Screenshot
The properties parameter is of type {[key: string]: string}
https://github.com/microsoft/ApplicationInsights-JS/blob/ed8632ae113cc7d013be825af05e1204b74a895f/shared/AppInsightsCommon/src/Interfaces/IAppInsights.ts#L28
Per the README.md, "objects are okay too". https://github.com/microsoft/ApplicationInsights-JS/blob/ed8632ae113cc7d013be825af05e1204b74a895f/README.md?plain=1#L270-L284
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
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
fixed in #2450