Need possibility to force transition to the state even if the parameters are the same

[stasgrom]

Hi,

I'm evaluating ui-router as a routing infra for our project. One of the issues I'm having at the moment is implementing refreshing the view. We have a refresh button which should reload the content of the view (because, for example, something might have changed in the server and we might get different data in UI). However trying to transition to the same state as we're in right now with the same parameters is blocked (I debugged and saw it in the code). So I would like to have some possibility/API to overcome this blocking.

The other possibilities, as I see, are worse:

1. Reloading the state by explicitly transitioning through an interim state, the only purpose of which is to trick ui-router into thinking something changed. This works but it reloads the state with all its ancestor states and thus builds the whole UI from the scratch, instead of reloading only the leaf current state.

2. Extracting the content of the state controller in a function and calling it from the refresh button handler explicitly. It works but looks bad from the architectural perspective, as it requires an extra step from the developer. One of the reasons I am evaluating the ui-router is because it allows to split the logic into state hierarchies directly, without introducing unnecessary functions, so I don't want to lose this advantage.

Thanks.

[jeme]

In option 2 you wouldn't have to extract the assignment of content to scope from the controller, instead what you could do was to broadcast an event that would then trigger the same data refresh in your controller...

If the scopes are in parent/child relation (they are if the views are nested within each other) you can even just call broadcast on the parent scope (I assume that is where your refresh button is)... Otherwise, if they are siblings, you will have to broadcast it on the root scope.

I think in this scenario, events make sense to use in that way... Where as if it was just sharing data between scopes, a service (possibly with events) would be the direction to go.

Not saying the Force Refresh wouln't be a good addition, but it requires some thinking and discussion before implementation.

[stasgrom]

Hi jeme,

thank you for responding.

if I understand you correctly you suggest something like (I simplified the code) :

$stateProvider
.state('parent', {
controller: function($scope) {
$scope.onRefresh = function() {
$scope.broadcast('refresh-event');
}
}
})
.state('child', {
controller: function($scope) {
$scope.$on('refresh-event', function() {
// Refresh your data here
}
scope.broadcast('refresh-event');
}
})

This will work, but it doesn't look tidy. This inevitably creates an unnecessary code bloating pattern, in each every time you need to implement refreshing functionality for a state, you:

1. Extract all logic to some event-handling function
2. Broadcast the event when the Refresh button is hit
3. Broadcast the event when you enter the state (or alternatively call the event handler directly, if you assign name to it)

Regards.

[jeme]

Close, but with the alternative you mentioned:

$stateProvider
    .state('parent', {
        controller: function ($scope) {
            $scope.onRefresh = function () { $scope.broadcast('refresh-event'); }
        }
    })
    .state('child', {
        controller: function ($scope) {
            $scope.$on('refresh-event', refresh);
            function refresh() {
                //Refresh Logic
            }
            refresh();
        }
    })

And yes it adds a bit extra code... But this isn't really uncommon practice in many other areas...
As i said... I think this is the best thing you can do for now, as implementing refresh in ui-router will take time to figure out the best solution...

Obviously your welcome to have a look at it your self.

[ksperling]

I agree with @jeme, a 'refresh' or 'reload' method sounds like it could be reasonable, but I think there are a few variations to account for / decide on, so it's not a quick one line fix. In particular

• do we reload the whole state, i.e. including all parent states or
• do we reload just the leaf state or
• do we allow individual views to be reloaded explicitly or
• should we allow all of those?

If we do reload states rather than just views, should transition events be triggered, and onExit/onEnter be called? Intuitively I'd say "no" for these ones. Maybe have a separate onReload callback and event instead?

[stasgrom]

Hi guys. Thanks, it seems like for the time being I will go with this approach.

[lrlopez]

@stasgrom For the sake of completeness, if you need to send the refresh message upwards to the parent states you could use $scope.emit instead of $scope.broadcast

@ksperling I've been thinking about your proposal. What about this? We could implement a reload() method on the states whose default behavior would be reload all the state views that have a reload: true parameter and also call an onReload callback, if defined. Also, calling the method with reload([true | false], [true | false]) would propagate the reload event upwards and/or downwards into the state hierarchy respectively.

Should we find it useful, we could also define that returning false from the callback would stop propagation in that direction.

What do you think? It's simple enough to cover most cases and won't add too much complexity to the code.

[timkindberg]

Wouldn't it always have to reload downward? Because if you are reloading a state that has children those child states would need to be reloaded too, I would think.

A slightly altered option (just throwing it out there) would be to have reload() only reload the state that its called on and all its descendants by default. That way you just have to decide how far up the state hierarchy you'll need to call reload().

Perhaps then its just an option of reload(true) to make it bubble upward as well.

[timkindberg]

Or maybe reload(stateName, bubble). So reload("contact") would reload the "contact" state and all of its descendants.

[lrlopez]

Wouldn't it always have to reload downward? Because if you are reloading a state that has children those child states would need to be reloaded too, I would think.

May be you only want to reload data regarding to that particular state or view (i.e. a sorting column switch) that doesn't bother to descendants. But you're right, the most used and intuitive behavior should be propagate to the child states. Why just not adding an optional parameter that defaults to true?

Or maybe reload(stateName, bubble). So reload("contact") would reload the "contact" state and all of its descendants.

I like that. We could support both syntaxes, it should be easy. If you don't specify an stateName we could just use the current one.

[timkindberg]

May be you only want to reload data regarding to that particular state or view (i.e. a sorting column switch) that doesn't bother to descendants. But you're right, the most used and intuitive behavior should be propagate to the child states. Why just not adding an optional parameter that defaults to true?

So it would be reload([stateName=null],[bubbleUp=false],[bubbleDown=true]) with first parameter being completely optional?

So then some examples:

• state.reload() - reload state and all descendants (where reload == true). Seems like reload: true should be the default if not specified.
• state.reload("contact") - reload "contact" state (regardless of where reload is called from) and all children.
• state.reload(true) - reload state, all descendants and all ancestors.
• state.reload(true, false) - reload state and all ancestors (not descendants).
• state.reload("contact", false, false) - reload only the "contact" state.

You like this?

[lrlopez]

Yes! 👍 I think it covers most use cases and is intuitive enough...

[jeme]

You will have to reload downwards as it is today, as a reload means that the view of that state gets wiped and reapplied and so does it's controller, so if you don't you will lose all the views under neath it and leave it in an uncertain state...

The most logical thing is to reload from top and down, and sure you could say "reload from this particular state and down"...

So it would be:

• reload('root');
• reload('root.child')
• reload() -> Root or just current?...

And i would advocate for it to stay that way.

[timkindberg]

Ok so then it would be reload([stateName=null],[bubbleUp=false])

And:

• state.reload() - reload state and all descendants (where reload == true). Seems like reload: true should be the default if not specified.
• state.reload("contact") - reload "contact" state (regardless of where reload is called from) and all children.
• state.reload(true) - reload state, all descendants and all ancestors.
• and technically you could do state.reload("contact", true) but that is identical to just reload(true).

[lrlopez]

I've got one question. Should be onExit and onEnter be called when reloading? May be we could define a default onReload behavior that calls onExit and onEnter but could be overridden.

[ksperling]

I think reload always by necessity moves downwards (because nested views will need to be recreated anyway), so I think it's just a question of where you start. It's probably most convenient if the default is to reload just the current leaf, so you'd have

• $state.reload(stateOrName)
• $state.reload() is short for $state.reload($state.current)
• and maybe $state.reloadAll() as more obvious sugar for $state.reload('')

Because we'll need to re-resolve, reload is going to be asynchronous, so it's probably easiest to treat it like a transition (for example in terms of what happens when another transition is started before the reload is complete and other edge cases like that).

I think a transition needs to carry along a little descriptor object that has 'from', 'to', 'fromParams', 'toParams' and any other information for the transition like 'reload': true/false, and make this available to onEnter/onExit. That way we could do away with a separate onReload callback. This could also be easily extended to pass along other hints from $state.transitionTo(), e.g. allowing animation to be disabled via 'animate':false or overridden.

It would probably make sense to also change the onStateChange* events to receive that transition object instead of 4+ separate parameters.