fix(ui-view): change $viewContentLoading to pair with $viewContentLoaded #2003
Conversation
The old $viewContentLoaded event wasn't needed for the one internal client (ui-view) because ui-view always ignores that event and acts on a $stateChangeSuccess event that follows right behind anyway. And it wasn't as useful to external clients as it could be because it wasn't delivered on every view update -- it was delivered only on state transitions that activate a state defining a view, and didn't deal with inheritance. Also, neither $viewContentLoading nor $viewContentLoaded events contained the name of the view loading or loaded. This change makes $viewContentLoading and $viewContentLoaded be emitted always in pairs, before/after updateView does the work of actually loading the view, and both events include the name of the view being loaded. This is a breaking change for users of the old $viewContentLoading event that relied on it being broadcast from the root scope, the precise time it was broadcast, the fact that it wasn't always sent when a view is loaded even if $viewContentLoaded will be sent, or the "options" parameter that was emitted with it. If people rely on any of that behavior and we can't break it, then we can restore the old behavior but I think there needs to be some other event which is reliably paired with $viewContentLoaded and contains the view name, and I can't think of a better name than $viewContentLoading for that event. Closes angular-ui#685.
|
I want this. |
@metamatt thank you, I think your analysis is correct. I think this change would also address some issues with
meh. I can't think of a scenario where you'd care about those things, except perhaps the options or $rootScope. I'm sure the one guy who relies on this will chime in to let us know eventually. @nateabele if we accept this PR, let's bump our next release to 0.3.0 just to keep the semver folks off our backs. Also, we'd need to merge the relevant bits into |
|
@kevinob11 @metamatt what do you use $viewContentLoading/Loaded for? |
|
I don't use it at all. The issue I was running into was views reloading twice after a notify:false view change. |
|
My use case:
(this and some additional thoughts are in #685 (comment)) |
|
And re
I 100% agree. I was just being pedantic about describing the change in behavior to give anyone who would care a chance to notice and speak up. I would expect that anyone who is using these events would consider this change an improvement. |
fix(ui-view): change $viewContentLoading to pair with $viewContentLoaded
|
@christopherthielen Just merged this. I don't remember what my objection was before, but it makes sense to me now. |
|
when will the next release happen? I want this 👍 |
|
+1 Need a release. The lack of consistent event pairs is a problem for me. |
|
+1 need a release |
|
+1 for release |
|
+1 for release 👍 |
|
+1 for release! 😃 |
|
+1 for release |
|
when will the next release happen? |
|
+1 release please :( |
|
+1 for release! |
|
+1 please release. |
|
+1 for release ! |
The old $viewContentLoaded event wasn't needed for the one internal
client (ui-view) because ui-view always ignores that event and acts on
a $stateChangeSuccess event that follows right behind anyway.
And it wasn't as useful to external clients as it could be because
it wasn't delivered on every view update -- it was delivered only
on state transitions that activate a state defining a view, and
didn't deal with inheritance.
Also, neither $viewContentLoading nor $viewContentLoaded events
contained the name of the view loading or loaded.
This change makes $viewContentLoading and $viewContentLoaded be
emitted always in pairs, before/after updateView does the work of
actually loading the view, and both events include the name of the
view being loaded.
This is a breaking change for users of the old $viewContentLoading
event that relied on it being broadcast from the root scope, the
precise time it was broadcast, the fact that it wasn't always sent
when a view is loaded even if $viewContentLoaded will be sent, or the
"options" parameter that was emitted with it. If people rely on any of
that behavior and we can't break it, then we can restore the old
behavior but I think there needs to be some other event which is
reliably paired with $viewContentLoaded and contains the view name,
and I can't think of a better name than $viewContentLoading for that
event.
Closes #685.