Add Raven.setExtraContext and Raven.setTagsContext.

[DouweM]

Resolves #213.

[DouweM]

API and semantics (merge rather than overwrite) based on raven-ruby.

[mattrobenolt]

How would you handle the case of unsetting these?

Lemme double check out Python handles this since that's our canonical reference.

[DouweM]

Seems to behave the same way: https://github.com/getsentry/raven-python/blob/683acffedc322f3f6ede606490d0e03e9a3a0b74/raven/base.py#L427

[mattrobenolt]

Are you trying to model this after tags_context and extra_context ? If so, this makes sense.

Also, if so, I think I'd prefer to keep naming inline and go with either setTagsContext() or just tagsContext.

[DouweM]

Or hmm, it doesn't, it completely overrides the extra/tags, instead of adding onto them. That's different from how the Ruby version behaves.

[mattrobenolt]

Aha!

Yeah, we definitely always merge in python and would prefer to model anything in raven-js after python.

[DouweM]

All right, I'll change that then. Annoying how the Ruby version don't adhere to that then :/

I don't mind the renaming, but shouldn't we rename/alias setUser to setUserContext then as well?

[mattrobenolt]

To be fair, we can also rename setUser to setUserContext as well to conform.

[mattrobenolt]

welp

[mattrobenolt]

Yeah, let's do that, rename and leave an alias that I'll deprecate in the future.

[DouweM]

All right, changes coming up in a minute, currently trying to whip up a backbone plugin :)

[DouweM]

Changes made.

[mattrobenolt]

Awesome! Thanks. 👍

[DouweM]

You should ping the Ruby guys their API is nonconforming by the way ;)

[dcramer]

The Ruby APIs match the Python APIs which conform to my made up spec. If anything, the JS API is nonconforming :)

[DouweM]

@dcramer Name-wise, yes, but check the source! In the Ruby implementation, new tags are merged with existing tags; in the Python implementation, new tags overwrite existing tags!

[dcramer]

Can we add setUser back as well? I wasn't paying much attention to this, but this is actually a pretty big caveat especially if its going to pop up in a minor version release.

[DouweM]

Already taken care of :) https://github.com/getsentry/raven-js/pull/219/files#diff-a4cb6d8063a6aea4bba2d6f10472b5f4R316

[dcramer]

Ah hrm, maybe this is just a documentation issue on our end then. Doh

[dcramer]

K addressed in getsentry/sentry@be71a58

We'll want to minor version bump to get the new things first-class I imagine

Thanks!

[DouweM]

This is really something to consider for the canonical Python API, but do we want to be able to not override, but add to the extra attributes?

I'm setting some generic extra attribute at Raven setup:

Raven.config(dsn, {
  extra: {
    request_id: "<%= request.headers["X-Request-ID"] %>"
  }
}).install();

And then later, depending on the exact place Raven is included, I'm setting some more extra attributes that aren't necessarily (known to be) available at config-time:

Raven.setExtraContext(
  {
    accommodation_id:   "<%= current_accommodation.id %>",
    accommodation_host: "<%= current_accommodation.host %>"
  }
);

Right now, the last call overrides the first, meaning request_id is lost, but I'd like the latter to append onto the existing extra attributes. Note that this is already how the Ruby Raven behaves, where I use a very similar scheme of two Raven.extra_context calls.

If we don't want to make this the default, how about adding an extra options object like { merge: true } or just an extra merge boolean arg to the setExtraContext and setTagsContext methods? This would be backward compatible, and could be added to all implementations that currently only do override.

[dcramer]

I dont have a strong opinion here. I think two best solutions are:

1. Initial context is different than local (and it is always merged when event is sent)
2. We add a merge option

There are likely rare situations where you could have multiple middleware (or similar) and want to set context at different levels, and have that merged in, but I'm not sure if it's worthwhile to cater to that situation.

[DouweM]

It's probably rare in the larger scheme of things, but because of the sort-of layered way our app is built, I would really appreciate a merge option. I also use this feature with the Ruby version, and I'd imagine it'd be useful with Python web frameworks as well.