$state.loaded

[timkindberg]

I think the loading indicator could just be a loaded property that is true once all views and dependencies have been loaded and resolved. The you can use the property in you templates to show some indicator if loaded while false. I think this should be a separate feature request because its SO common.

Also, Maybe a directive to automatically display a "loading.html" partial or have it be a setting on each state?

[ksperling]

There is currently a $state.transition property, which is a promise for the next state, i.e. it is resolved when the state transition completes (or rejected if it fails). $state.transition is never null.

The way things are currently implemented, views only update once all dependencies are resolved. This is because the view directive needs to create the controller at the time the view is created, and the controller needs the dependencies.

I was thinking of having a $state.next property which is non-null only if there is currently a transition in progress, so that you could use that to display a loading indicator (this would probably be done in a global place outside any ng-view) with something like ``ng-show="$state.next"`

[timkindberg]

I'm not sure that $state.next says Boolean to me. I would assume it would be a state object of the next state being loaded. I think we need a loaded property; I hate to play this card, but ember's routes have them and they use them quite a bit in examples. I just think people are going to be looking for it. I think it's so common that we need a nice obvious solution for it.

[ksperling]

yeah next wouldn't be a boolean, but you could use it as one -- it would be non-null if transition is in progress.

We could call it 'loading' rather than next?

That would also let you do something along the lines of <div ng-show="{{$state.loading}}">Loading {{$state.loading.title}}"</div> if you had a custom 'title' property on your states.

I think providing access to the state that's being loaded can be very useful compared to just a boolean.

[timkindberg]

Hey I like that! I just think people will be looking for a loading
property, but that is even more powerful.

Man, its just that it may not be as clear as just having two separate
properties, both loaded and loading. Its the kind of thing where if we only
had 'loading' we'd HAVE to put it in our documentation that you can use it
in ng-show. And it would be this thing where theres 50 stack overflow
questions about it and always the same answer "use $state.loading" "Oh cool
thanks!". Where as if we had a "loaded" boolean property people would find
and use it easily. So I think if it wasn't too much extra work we may want
to do both "loaded" and "loadingState" ("loading" feels too much like a
state of $state). We should see what others think too, since we are going
back and forth on this.

On Sat, Feb 16, 2013 at 10:53 PM, Karsten Sperling <[email protected]

wrote:

yeah next wouldn't be a boolean, but you could use it as one -- it would
be non-null if transition is in progress.

We could call it 'loading' rather than next?

That would also let you do something along the lines of

Loading {{$state.loading.title}}"

if
you had a custom 'title' property on your states.

I think providing access to the state that's being loaded can be very
useful compared to just a boolean.

—
Reply to this email directly or view it on GitHubhttps:/angular-ui/router/issues/23#issuecomment-13680316.

Thanks,

Tim Kindberg

[ksperling]

I guess we can put 'loaded' down on the nice-to-have conveniences list... I'd just like to get the essential APIs and then see how many of the things we now predict will be very convenient really are.

If I saw both 'loaded' and 'loading' in the API docs I'd wonder if their semantics differ in some subtle way or why else somebody would add a property that's only saving a single negation.

I've previously worked with the rule that in order to be "allowed" to add a utility / convenience method or property on top of an existing API, you have to have done it the pedestrian way at least three times first. I think we should follow a similar approach and get some real world use of the bare-bones API and then see where the convenience APIs would really be useful in practice.

[timkindberg]

That's fair.

[stale]

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs.

This does not mean that the issue is invalid. Valid issues
may be reopened.

Thank you for your contributions.