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

Allow settings to be functions? #79

Closed
JacobEvelyn opened this issue Sep 23, 2014 · 9 comments
Closed

Allow settings to be functions? #79

JacobEvelyn opened this issue Sep 23, 2014 · 9 comments

Comments

@JacobEvelyn
Copy link

I was wondering if you guys had thought about allowing settings to be functions. For instance:

Bugsnag.user = function() {
  return getCurrentUser() || {
    id: 7,
    name: "Conrad Irwin",
    email: "[email protected]"
  };
};

This would let us keep our Bugsnag code all in one place, rather than putting it in various places (here, when the user logs in, logs out, etc.).

I'd be happy to whip up a PR for this if it's something you guys agree with.

I'm also brand new to Bugsnag so let me know if there's an alternative approach I missed!

@ConradIrwin
Copy link

I think you can already use Bugsnag.beforeNotify for this:

Bugsnag.beforeNotify = function (payload, metaData) {
  payload.user = getCurrentUser() || {
    id: 7,
    name: "Conrad Irwin",
    email: "[email protected]"
  };
}

We've found that most people are able to just set their user up-front, so it's probably not worth the complexity of allowing Bugsnag.user to be either a value or a method.

@JacobEvelyn
Copy link
Author

Ah great, thanks.

@JacobEvelyn
Copy link
Author

Also, if you wouldn't mind, could you clarify how most people set their user upfront? It seems like most apps are written for use by more than one user, so I feel like I'm missing something.

@jmshal
Copy link

jmshal commented Sep 23, 2014

If you're asking about how the front end configuration is done;

Personally, I pretty much handle it the same way as all the examples in the README. It doesn't need to be much harder. I push all the information to the client during page load, so I have the ability to include post data, and even session data, that would otherwise be slightly fiddly to deal with than an Ajax request back to the server. On top of that, I also generate a summary of loaded resources when the error occurs, which is helpful if you forgot to include a library, where it is needed. Eg. If I ever get a '$' related error, I check whether jQuery has actually been loaded, before diving into any code.

@JacobEvelyn
Copy link
Author

Ah, that helps a lot, thanks! I forgot that not everyone works in the land of single-page apps :)

@jmshal
Copy link

jmshal commented Sep 24, 2014

I see what you're saying now. I think it's up to you as to how you want to encorporate Bugsnag into your single page app. Because everybody does single page apps slightly different, it's hard to generalize how Bugsnag would work in all scenarios.

FYI (if it helps) there is a angular.js 'attachment' for Bugsnag. Which is fairly helpful for getting started.

@JacobEvelyn
Copy link
Author

Thanks. By "attachment," are you referring to this? https://github.com/wmluke/angular-bugsnag

@jmshal
Copy link

jmshal commented Sep 24, 2014

Ahah. Yes I do. I just noticed your PR, so I assume you know of it 😄

P.S. Nice first name.

@JacobEvelyn
Copy link
Author

😃

kattrali pushed a commit that referenced this issue Apr 22, 2021
Don't exit in the default onUncaughtException
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

3 participants