You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can work around this by using a different overload of the function (the one that takes a properties object). But why this difference?
This seems to be part of a consistent trend in Mixpanel's type definitions: they seem like a hasty afterthought. For example, the PropertyDict type is defined as {[key: string]: any}, which will accept any object, including objects containing values that Mixpanel definitely can't handle. In fact, it will happily accept objects that aren't even serializable to JSON! These type definition defeat much of the value of using types. They can't stop users from making most of the errors that would actually matter. (But the set_once bug will prevent users from setting properties to number values.)
The text was updated successfully, but these errors were encountered:
In the types,
set
can take a number:but
set_once
can't:I can work around this by using a different overload of the function (the one that takes a properties object). But why this difference?
This seems to be part of a consistent trend in Mixpanel's type definitions: they seem like a hasty afterthought. For example, the
PropertyDict
type is defined as{[key: string]: any}
, which will accept any object, including objects containing values that Mixpanel definitely can't handle. In fact, it will happily accept objects that aren't even serializable to JSON! These type definition defeat much of the value of using types. They can't stop users from making most of the errors that would actually matter. (But theset_once
bug will prevent users from setting properties to number values.)The text was updated successfully, but these errors were encountered: