add flag in .transitionTo() to allow ability to disable broadcast of $stateChangeSuccess

[mattbroekhuis]

Wanted a way to update $stateParams using .go() or .transitionTo() without destroying re-rendering the view. This seems to allow this to happen. Not sure if it would be deemed as a good option to include to end-user, or if it fits into the larger picture of what you're trying to do, but figure it never hurts to have more options? Suggestions encouraged. I will add to the docs if you decide to include it.

[nateabele]

I don't think this is a good solution to the update problem posted above, but may be useful for other general cases, especially since we already have a notify flag in $view.load().

I'm fine with it provided a few superficial fixes: (1) I think the key name should be changed to notify for consistency, and (2) the code formatting needs to be brought into consistency with the rest of the codebase.

[nateabele]

Oh, and cc'ing @timkindberg, @ksperling, @stu-salsbury and @eahutchins for comment.

[laurelnaiad]

may be useful for other general cases, especially since we already have a notify flag in $view.load()

Aside as the purpose of hacking away the rerendering, is the case for there being usefulness to not raising an event a performance issue?

I guess that ultimately as a listener I'd like to be able to distinguish between a change in which state is active and a change in stateParams that doesn't involve a change in state. But I can't think of a good reason to suppress the event altogether (except perhaps as a hack to get a view not to rerender, and that to me is too much of a hack).

BTW -- on the subject of events and performance -- I would like an option on $stateProvider that changes the event raising from $broadcast to $emit because I'd personally want to centralize the listening in another service and not pay the penalty (but that's just me).

[timkindberg]

No opinion. I'll defer to you smart people.

[nateabele]

@stu-salsbury

Aside as the purpose of hacking away the rerendering, is the case for there being usefulness to not raising an event a performance issue?

It's a being-nice-to-the-programmer issue, and letting them control things as they so desire. In the words of a fictional wizard, 'even the very wise cannot see all ends'. We can't predict what people are going to want to do with our software, so we shouldn't presume to.

I guess that ultimately as a listener I'd like to be able to distinguish between a change in which state is active and a change in stateParams that doesn't involve a change in state. But I can't think of a good reason to suppress the event altogether (except perhaps as a hack to get a view not to rerender, and that to me is too much of a hack).

If you're writing a 3rd-party library that someone else is using, and they're suppressing events that you're listening for, then they should understand the caveats and act accordingly. If you're writing a 3rd-party library that that's firing state changes with events suppressed, well, that's inconsiderate and you should know better (not you personally, I'm sure you do).

BTW -- on the subject of events and performance -- I would like an option on $stateProvider that changes the event raising from $broadcast to $emit because I'd personally want to centralize the listening in another service and not pay the penalty (but that's just me).

I've been thinking of a slightly more flexible subscription API, so you could swap out $rootScope with a series of scopes that should be subscribed to events. We can get into that after the next release.

[nateabele]

@Broeks Given the current consensus, I'm inclined to merge this, but it needs to be updated according to my notes above (please squash your commits when you're done). Thanks.