Open/close modal view from app.component breaks navigation

[MartoYankov]

If there is no issue for your problem, tell us about it

When you open a modal view from app.component and then close it, the default router navigation seems to repeat onto itself. Pressing the back button navigates back to the same home page. Connected to #1502

Which platform(s) does your issue occur on?

• Both
• emulator or device.

Please, provide the following version numbers that your issue occurs with:

• CLI: 4.2.2
• Cross-platform modules: 4.2.0
• Runtime(s): 4.2.0
• Plugin(s): (see playground example)

Please, tell us how to recreate the issue in as much detail as possible.

Use the playground example below. The login modal page is opened at the start from app.component

1. Tap on "Successful Login" -> The modal will close
2. Tap the back button -> One navigation to the same home page will execute

Note: Implementing one navigation inside the modal view seems to fix the issue.

Is there any code involved?

https://play.nativescript.org/?template=play-ng&id=2ceg6i&v=2

[Eonfuzz]

This is causing some serious issues on a project I'm working on.
Is there a working fix?

[MartoYankov]

@Eonfuzz Yep, as I mentioned in the issue - implementing ti as a modal view with navigation in it works around the issue. Here is an example - https://play.nativescript.org/?template=play-ng&id=XfRwGm&v=8.

[kkoates]

What if we added an option like disableNavigation: boolean to ModalDialogOptions that lets us control whether or not closeCallback executes this.location.back():

nativescript-angular/nativescript-angular/directives/dialogs.ts

Line 132 in 6155f02

this.location.back();

This new option, disableNavigation, would be false by default as not to interrupt the current working use cases of the modal but give flexibility to others to control their own navigation after the modal closes.

[Eonfuzz]

@MartoYankov thanks for the quick reply!

I currently do have multiple navigation steps in the modal view, if there is only ever a single navigation inside the modal there is no issue. But if there is more than one navigation entry it causes the weird navigation behaviour.

On hindsight, it may be a different issue entirely - but it almost looks like it creates a seperate routing instance in addition to the original one.

Check out this gif, I open the modal when I click on [Roller Blinds] at the bottom left hand corner.
After going back to the previous route, you can see the app hangs and pauses before the route starts going haywire.

I'll try to put together a playground that reproduces the issue, but basically...

• The modal is inside a lazy loaded module
• Almost identical to the documentation, except the modal has more than one route

[MartoYankov]

@Eonfuzz Thanks for reporting this. It definitely looks like a different bug. If you can reproduce it in a simple playground and open a new issue it would be great.

[NgxDev]

@MartoYankov I'm not 100% sure that my case illustrates the exact same problem, but I got here looking for a way to have a global custom-dialog service. I thought I nailed it when I said "ok, I'll handle the showDialog in the root (app.component) and listen to actions dispatched from my store, and make the decission to show the dialog there, in one place, with whatever parameters I need to"

My use case: I need to show dialogs to the user, with custom content/design (not supported by the standard dialogs initialization options), depending on certain conditions known either A) at an interceptor level or B) in my store/state management, as a result of different dispatched actions.
And having to repeat code like this.modal.showModal(MyDialogComponent, myDialogOptions) in 10-20 or more different components is not really acceptable. It should be done at a service level or, like I said, from state management or even from http interceptors. While it would still be possible to also send the ViewContainerRef of the 'current' component to my store, along with any other payload, and use that ref, that's still unacceptable design for my code, having to send a ViewContainerRef in all the payloads of any store action dispatched. Plus, that would be even more difficult to achieve when having to simply trigger the dialog from an interceptor, no state management involved.

I don't really understand the design decision to have to pass a ViewContainerRef to the custom dialog, why wasn't it made to work without that, like the standard dialogs do. In my oppinion, a dialog needs to be absolute, independent of any view/component.
But that's maybe because I don't know how native mobile development really works. Also, I'm a NativeScript newb here, just got started a couple months ago with my first app.

Anyway, long story short (too late 😄) in case it helps and is a valid reproduction, I made a repro here: https://play.nativescript.org/?template=play-ng&id=AruVA6
Not sure if it satisfies this issue 100%, but it seems like more or less the same behavior: getting redirected to '/' when dismissing the dialog.
So, once the app opens on the '/' route (where I render the Home component):

1. Navigate to the /about route by tapping the "About" button
2. Tap on the "Open dialog" button. This tells the app.component (through a service) to open the dialog.
3. Dismiss the dialog.
4. NativeScript redirects you back to the root '/' route.

Expected behavior: remain on whatever route you're on.

@kkoates: What if we added an option like disableNavigation: boolean to ModalDialogOptions [...]

I guess this would be the most viable solution, in order to not introduce breaking changes

P.S. On the NativeScript Community slack workspace, someone said that I could potentially use topmost() to open a custom dialog, without passing a ViewContainerRef, but couldn't find anything on that when I googled it. And didn't want to bother that person further. Is that possible?

[MartoYankov]

@MrCroft Thanks for the scenario.

In iOS dialogs are modal views. There is no equivalent to the Android dialogs, so we are always using a modal view. Also, in iOS a modal view (presented view controller) is always shown by another view controller (presenting view controller). The ViewContainerRef is important for modal views that embed navigation in them. It doesn't make much sense for dialog like popups. Currently, the API doesn't provide distinction between the two. We are still discussing this at the moment, so I don't think we can provide something like this in the next release.

The issue with redirecting to '/' is logged as a bug in the router and it should be fixed with the next release of nativescript-angular. As I wrote in the issue, there is a workaround - make one navigation inside the modal view.

[valera1401]

I'd like to add that if you call Router.navigate in dialog callback, you will go to the new page and will immediately return back to the previous page.

this.dialog.showModal(SomeComponent, {
fullscreen: false,
viewContainerRef: this.viewContainerRef,
}).then(() => {
this.router.navigate(["some path"]);
});

[daveware-nv]

EDIT: I decided to open my own bug: #1661

The modal seems to seriously break navigation in a variety of ways, here are problems I'm observing that I think are related:
With page-router-outlet:

• Closing a modal that was opened on a page navigated to with skipLocationChange: true, will cause a navigate to the previous page
• Closing a modal that was opened on a page navigated to with replaceUrl: true, will a navigate to the previous page

With router-outlet:

• RouterExtensions.canGoBack() will cause a crash within the dialog, and after the dialog closes until a navigation action is performed. (TypeError: Cannot read property 'states' of undefined File: "file:///data/data/org.nativescript.nstest/files/app/tns_modules/nativescript-angular/router/ns-location-strategy.js, line: 227, column: 22)