2

I am trying to get the router.navigateBack function working correctly using Durandal 2.0.1.

I have a viewmodel that can create an entity that we'll call lead. After creating a new lead I want to replace the uri so that it has the edit lead route instead of the create lead route and also replace it in the history. I call the following function after save:

router.navigate('#lead/' + vm.lead().id(), { replace: true, trigger: false });

here is the route description in my config file

{
    route: 'lead(/:leadId)',
    moduleId: 'lead/lead'
}

Then afterwards when I call

router.navigateBack();

It navigates to the expected route but always causes a full page refresh. I am trying to avoid the full page refresh and simply navigate as usual.

In durandal 1.0 I used to just call

router.replaceLocation();

To accomplish this same task and it would work well. I'm wondering if I'm missing something here.

John Gurski
  • 91
  • 2
  • 6

1 Answers1

1

Try the following: 

var leadId = vm.lead.peek().id.peek();
router.navigate('#lead/' + leadId, { replace: true, trigger: false });

I believe your observable has a dependency that's causing a complete recalculation. We can use Knockout's peek() to obtain a value without creating a dependency.

  • Thank for your help. This worked perfectly! I have a similar problem that is occurring when trying to delete a lead. when deleting I call – John Gurski Apr 23 '14 at 15:20
  • the same type of method but use {replace: true, trigger: true} to navigate away and replace in history after deleting. I get the same problem with the page refresh when I call the router.navigateBack() method thereafter. I replaced the reference to the observables with the peek reference but it didn't solve the issue when trigger: true. I did workaround for this by not replacing the route and just canceling navigation in the canActivate method when trying to navigate to a deleted record so this isn't a big issue for me but if you know where I went wrong again I'd appreciate the input. – John Gurski Apr 23 '14 at 15:25
  • wow.. Just realized this did not fix my problem... also realized that this problem is specific to the google chrome browser. Whenever I call router.navigateBack() and attempt to naviagte away from a route that has been set using router.navigate('#...', { replace: true }) I get the full page refresh – John Gurski Apr 23 '14 at 16:00
  • @JohnGurski Just following your comments. In the last comment, you say "Just realized this did not fix my problem." Were you referring to _my_ suggestion, or to something in your preceding two comments? If the former, then I need to look deeper. Thanks. –  Apr 23 '14 at 21:11
  • Your suggestion did not solve my problem, please ignore my first two comments, I was deceiving myself! My last comment pretty much nails the problem down. navigateBack() always works fine for me except for when I am navigating away from a route that was set using {replace: true} (only occurs in chrome, not IE11). – John Gurski Apr 23 '14 at 21:54
  • I've followed the stack back to line 290 in the durandal/history module where the history.navigateBack function is defined. It appears that instead of using hash routing, chrome decides to call my MVC controller where the index.cshtml view is which contains the app/main script. I am wondering if this has something to do with the fact that I don't have the index.cshtml file in the root folder but instead in my views folder for the corresponding MVC controller. I appreciate your efforts! – John Gurski Apr 23 '14 at 21:54
  • @JohnGurski You know, I've never put the index.cshtml file anywhere but the root. Perhaps you should relocate it to the root and see what happens. I'm wondering how it's even reaching the index file anyways. –  Apr 23 '14 at 22:28
  • I use this approach so I can leverage the Identity Authentication system easily. I have the authorize attribute on my app controller and upon login I redirect to the index method on the app controller which contains my App/main script. I'd like to keep it this way but I'll check on a sample app if the problem still occurs with the index at the root – John Gurski Apr 24 '14 at 00:42