Allow ion-tab to work with router-view

[riderx]

Pull request checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
• Build (npm run build) was run locally and any changes were pushed
• Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

i don't use ion-vue-router in my project, but i cannot use ion-tab without it, instead of hacking routing it made possible to use it without.
The only change is there are no animation any more.
To work the

Issue Number: 24192

What is the new behavior?

• Allow use of ion-tab with basic routing component

Does this introduce a breaking change?

• Yes
• No

Other information

[riderx]

@liamdebeasi hey sorry to open this again but i was hit again by this issue while building https://github.com/Cap-go/capgo
I found a way to make it work for both worlds.
I Added a warning to prevent ionic team to get support issue, if a user doesn't have transition because they use RouterView instead of your outlet.
I hope this is more acceptable solution

[sean-perkins]

@riderx can you share what issue exists in the Ionic Vue Router that prevents you from using it? I can let the other team members weigh in here, but we do not want to encourage developers to be able to eject from our implementations to mend other solutions in place.

We have this stance for multiple reasons:

1. We built the routing integrations that exist to offer native-like transitions for web-native applications built with Ionic. Using any other solution in place without those transitions is not something we want to allow, as it degrades from the value of an Ionic application.
2. Using unsupported routing integrations can lead to unknown bugs and gaps in features. By making it "allowed", we invite these issues to exist and cause additional overhead into the maintenance of the project.

[riderx]

Hey @sean-perkins thanks for the answer.
You can find my old issue here:
https://github.com/ionic-team/ionic-framework/issues?q=is%3Aissue+author%3A%40me+is%3Aclosed

The main issue who stop me using ionic-router is sub routing.
With the vuejs ionic router we cannot use sub route in page, and that use for layout system in vuejs apps, in desktop website.

You can check the code here https://github.com/Cap-go/capgo
the sub route is used to render markdown blog page.

I totally understand the the fact that will degrade the experience that why i put the warning.
I would prefer you allow sub routing but last time i asked it seems it was not in the plan.
The last thing i can do otherwise is to publish my solution in npm to let others get the benefit to ionTab without disabling the sub route feature of vue-router

[sean-perkins]

@riderx after discussing with the team further, the problem you are experiencing is a result of how you are autogenerating routes based on the file structure: https://github.com/Cap-go/capgo/blob/main/src/main.ts#L6

You should not be generating sibling pages in tabs as children. Instead they should be siblings.

For example:

• /tabs/tab1/child and /tabs/tab1 should be siblings.

There should not be a /child route specified as a child of /tabs/tab1.

This is explain in the docs: https://ionicframework.com/docs/vue/navigation#shared-urls-versus-nested-routes

I am going to close out this PR, as this is not a change we are wanting to support. Feel free to open an issue if you run into problems when following that documentation and we can help assist.

Thanks!

[riderx]

Understand your feedback, but please understand mine.
i cannot use ionic in my stack because of that, i did try many things since the last issue in December, and still cannot do it.

What i do now to have SSG/SSR working ( in Captime app ) is:
Duplicate the whole project for web into a new repo made with Vitesse without ionic routing at all. And keep both in sync.

This doesn't make really sense for me to have to do that, even i understand what you think, you have to consider usages.

I can't have both working together as you can see in Capgo, i have no SSG implementation otherwise, so no Meta, no SEO ...

My last option is to totally stop to using ionic and switch to Quasar who is really made for Vue users.
As it, it's not flexible enough for people who use other packages than just ionic...

[sean-perkins]

@riderx I am unfamiliar to Vitesse. Does it prevent you from adjusting the declaration pattern for routes that are registered to Ionic Vue's router?

The issue you describe:

The main issue who stop me using ionic-router is sub routing.
With the vuejs ionic router we cannot use sub route in page, and that use for layout system in vuejs apps, in desktop website.

Is a supported feature of our router integration. You will just need to adjust the way that routes are declared to take full advantage of it. By refactoring your route definitions from being nested, to siblings, you should be able to have the navigation pattern you desire with tabs, without using router-view or Ionic having to open up the routing integration layer.

[riderx]

@sean-perkins yes vitesse create the routing automaticly from folder architechture and handle the SSR/SSG system for you for SEO purpose.
So to add ionic i had to disable SSR/SSG who is already a big loss and i had to create my own ionTAB component to have my blog section working because it use sub routing to generate from file in markdown blog articles on my web version of my SaaS.
What i ask is just a flexible way for routing to work in combinaise with other tools. 🥲
as you can see my other issue there for SSR/SSG : #24991 (comment)

[sean-perkins]

@riderx is there any time commitments/deadlines you are up against with this request? I see the pain points you are facing and have also briefly looked into what other libraries do to see if our approach is too restrictive. I would like to draft an internal feature proposal with the team and review it, before proceeding with this request.

While I can see the benefit of supporting alternative router outlets for web-desktop implementations using Ionic, I also believe tabs should potentially not require a router outlet at all. If I can de-risk this approach internally, it would likely lead to removing the opinionated errors we throw and allow you to integrate as you please. Ionic would obviously not support custom 3rd party solutions, but we would also not prevent you from experimenting with them as well.

[riderx]

@sean-perkins i use ionic since years and would love to continue using it!
Learning quasar from 0 is not my goal!
If you look for solution to let this work for desktop, it's wonderful news!

What you propose is perfectly what i expect, allow a bit of flexibility for usage .
i will split my code in 2 projects for now, and if as timeline we can have solution around this summer, that good to me :)
Thanks a lot

[riderx]

Just saw today the maintainer of vitesse ask about how people do animations between components or page in vue.
Can be interesting to read answers :
https://twitter.com/antfu7/status/1509587065771798528?s=21&t=VWXjNbN9g-DVMRUzT5fA_g
The quasar answer to that, look less magical than ionic one, but also more powerful.
I do really believe of have animation outside of router can be really more flexible.
Maybe ion page csn become the host of that?
Or just ionPageAnimation component around normal router?
This is huge réflexion, share your thoughts with the community can be very helpful :)

[sean-perkins]

The animation pattern demonstrated in that tweet is both a very different feature and implementation pattern than what Ionic Framework does for page transitions. Ionic maintains the previous view in the DOM, so that we can animate a swipe-to-go-back experience correctly, without screen jittering from having to render the previous view (it is already rendered, just off screen). This aligns with native app page transitions.

The tweet demonstrates cloning element nodes and then transitioning that cloned node into a new page. You can technically already do this with Ionic or any web solution. It just requires complexities of knowing the start and end position of your transitions and re-attaching event listeners, which is why it is extremely unlikely Ionic would solve that problem for you, as it is an application detail.

You could this without cloning the node, but it wouldn't be as smooth of an experience, i.e. I did it previously with Ionic v4: https://twitter.com/seanfperkins/status/1136502546577723397.

[riderx]

@sean-perkins thanks for the mind-blowing moment, now i understand a lot better!

i didn't understand you modified the Vue router to have kept the view in the DOM, i saw the init function where never call again but couldn't explain why.

This should be explained in this page:

https://ionicframework.com/docs/vue/navigation

That will solve a lot of unnecessary fight with ionic router!
For me, the router was just about transitions, that why it's feel "useless" to overload the whole router for that.
I'm sorry.