Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to add properties at the root level of messages in @segment/analytics-node #731

Closed
lzear opened this issue Dec 19, 2022 · 1 comment

Comments

@lzear
Copy link

lzear commented Dec 19, 2022

Hello

We are updating from analytics-node to @segment/analytics-node (because of segmentio/analytics-node#309), and we're facing a small issue that could be worth addressing or documenting: we're placing some custom properties at the root of the tracked events, even though I understand this is not how the API is documented (docs). It was working with analytics-node but it breaks with @segment/analytics-node.

(option 1): Would it be possible to change @segment/analytics-node and @segment/analytics-core so extra properties are placed at the root of the tracked object, so there is one less breaking change with analytics-node?

(option 2) If not, I think it would be beneficial to add warning in packages/node/README.md because it's probably not only our team that made this mistake 😄


If option 2 is chosen, the update in packages/node/README.md could look like this:

Differences from legacy analytics-node / Migration Guide

[...]

  • Preventing custom properties to be set directly at the root of the event
    // old (this was possible even though that is not how the API is documented)
    analytics.track({
      userId,
      event: 'Bookmarked Article',
      title: 'Moby Dick',
      author: 'Herman Melville',
    })
    
    // new (custom properties placed on the root will be lost)
    analytics.track({
      userId,
      event: 'Bookmarked Article',
      properties: {
        title: 'Moby Dick',
        author: 'Herman Melville',
      }
    })
@silesky
Copy link
Contributor

silesky commented Dec 21, 2022

@lzear I really appreciate you letting us know about the legacy behavior! I think this is something we'd rather not port to the new SDK, as we'd prefer conventions / predictability in our API over saving keystrokes.

The latter "documentation" solution is the right one! Feel free to make a PR; or, I can do it after the holidays.

@silesky silesky closed this as completed Feb 25, 2023
@silesky silesky reopened this Feb 25, 2023
@silesky silesky closed this as completed Mar 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants