Frame ids being renamed from navigating in tabview with clearHistory

[vbro1293]

Version

2.2.2

Reproduction link

https://play.nativescript.org/?template=play-vue&id=b9T9VZ&v=4

Platform and OS info

iOS 12.4 / Android 7

Steps to reproduce

• Navigate to a full page from within a tab (tap tab 'two')
• Navigate to a tabview from this page using clear history (tap 'nav to FullPage')
• Attempt to navigate to nested page (tab tab 'one' then 'nav to NestedPage')

What is expected?

• Should navigate to nested page within tabview

What is actually happening?

• Navigation breaks, which appears to be because the ids of the frames in the tabview gets reassigned to ${framename}1 when the nested navigation page requires frame: ${framename}

---

• Attempting this flow again, resolves the issues, as the frame names revert to the original assigned frame names.

This is the base structure of an app which would require quite a large navigation restructure, so any workaround or fix would be appreciated without disrupting this specific component structure i.e. frame within a tabview within another frame.
Thanks!

[msaelices]

@vbro1293 the problem is that the ID in the <Frame id="foo"> NS-Vue Frame component may not correlate with the NS frame ID, because in the code we avoid ID clashing by using an internal counter here:

https://github.com/nativescript-vue/nativescript-vue/blob/master/platform/nativescript/runtime/components/frame.js#L52

I think the $navigateTo function should not use the passed Frame ID when calling to NS and using the Frame.properties.id one, which would be frame11 or frame22 in this case (appending the idCounter variable)

[rigor789]

I've actually commented out the internal counter in my local version of the latest alpha. I'm trying it in a real app, and checking if I run into issues with that. So far it has been fine without it. The original reason for this was that sometimes the frame would get created before the old one would be destroyed (or some similar situation, I actually don't know for sure).

@msaelices the frames are resolved based on their id, so unless you pass the frame instance to $navigateTo you can't figure out the correct id to use. Or maybe i misunderstood your idea.

Anyways, I think for the next version I will remove the internal counter, and just override the frame based on the ID. The only issue with this would be if the user uses the same id for multiple frames. We can't warn about this, because you don't know for sure if the frame id is in use, or just not destroyed yet.

[msaelices]

@rigor789 commenting out the properties.id = this.$props.id + idCounter++; line makes the app work.

Why is exactly needed to have the idCounter? I mean, there is only a change to have an ID clash if there are two frames with the same ID in the same NavigationEntry, right?

[rigor789]

@msaelices I think there was a case where the same frame would get re-created before the old instance was destroyed. And the id would clash. I don't think this is a problem though now that I think of it, because you likely always want to access the "latest" frame with a given ID.

With that, i think it's safe to remove the idCounter, and just override the older frame instance in the frame util.

The only problem this would cause, is if the user uses the same id simultaneously on two frames.

And no, the NavigationEntry itself wouldn't cause a clash - it just stores the passed id, and finds the frame based on it!

[msaelices]

@rigor789 Just read your previous comment :)

[msaelices]

I will work on it.

[rigor789]

I have a version without the idCounter locally, with some Modal fixes for devtools. I'll have to clean up my changes and push them soon. I'll probably release it as 2.5.0-alpha.1 too.

[vbro1293]

@rigor789 @msaelices - Thank you both for looking into this and providing a fix!

[rigor789]

I will release the fix as an alpha release soon!

[nativescript-vue-bot]

We are locking this issue because it has been closed for more than 14 days.

If the issue comes up again please open a new issue with additional details.