How to prevent router from navigating to self?

(Please forgive me if this is a duplicate; I searched for topics covering this and didn’t see anything.)

One use case for our app is within an iframe. Under certain circumstances, the src for the frame is set to the same url it’s already at. Trying another mechanism, using iframe.contentWindow.location.assign(theSameHrefAsItAlreadyHas) has the same surprising behavior, and that is this: Aurelia’s router navigates to the same url it’s already on. The
existing view model’s destroyed and the new one constructed leaving us at the same point from which we came.

What I’m wondering is this:

  1. Is there a way to configure the router such that it will not perform an action when all of the parameters end up the same as the model it’s already on?
  2. If there isn’t a stock/default mechanism for this, what’s the right/best way?
  3. Are there any obvious downsides/consequences to behaving as we’re hoping, which I’m just not foreseeing?

We’ve only just begun looking into this, but were considering adding an authorize step with a next.cancel when we see route parameters not changing. Is that advisable?

1 Like

Is this what you want? http://aurelia.io/docs/routing/configuration#reusing-an-existing-view-model

With navigation strategy no-change (base on the comparison between old/new params) you can tell the router to stop.

2 Likes

I’m not sure. Since the reusing the view model bit is talking about change to the view model centered around activation strategy and not a navigation strategy) I think either that link is accidentally to the wrong anchor, or I’m not quite understanding the suggesting.

I’m admittedly tired, so it’s entirely possible I’m just not totally processing how that would fit.
I’m going to revisit this when I’m more rested to see if it makes more sense to me.

Most of the time, I think we need a complete change in view model. It’s just the case where (and the route can totally predict this) the router’s fixing to leave THIS instance of the view model only to end up in the exact same spot (all of the same params), after some tear-down and re-build.

What I think I’m getting at is it’s not clear to me how something like this would (appropriately) navigate and create new view models in the majority case, but avoid doing so in this one.

While I’m in here – THANK YOU @bigopon for taking the time to consider and respond to this, and for the time you spend helping people out in here generally (You’ve been doing this a LONG time). I appreciate you.

3 Likes

I’m not sure. Since the reusing the view model bit is talking about change to the view model centered around activation strategy and not a navigation strategy) I think either that link is accidentally to the wrong anchor, or I’m not quite understanding the suggesting.

Oops, yes I mixed it up. Though I had a look at the code again, and the source code here


and here

suggests that you have a NavigateInstruction as the first parameter in your determineActivationStrategy. It may or may not be too late for the desired outcome related to router & timing, but probably it gives you all the information that you can work around with.

While I’m in here …

Thank you to you too. I :heart: everyone who contributes to the little community we’ve got here.