This is a very general question, but I’m wondering if there’s someone actively working on the Ionic-React library? And if so, are there plans to improve the integration with react-router?
The amount of frustration from poor documentation and bugs within this part of Ionic makes me want to drop this framework as a whole. The bugs are always difficult to troubleshoot because documentation is extremely vague and although sometimes working around Ionic has been okay, on numerous other occasions it just causes more bugs. I also tried to do the tiniest commit ever to some Ionic documentation a few months ago, I submitted a pull request, but it’s never been looked at, so I’m wondering if the Ionic-React library is just dead or what.
I’d really love this framework to work for me. There’s a lot I like about Ionic. Please someone restore my faith lol.
I started using Ionic last year, and lack of documentation for the router specifically caused me a lot of pain.
That said, I think part of the problem is that react-router itself is a bit buggy, as the team that built it basically moved on to remix for a couple years and then came back with react router 6, which Ionic doesn’t support yet (feature request for react router 6 support here).
The Ionic React library certainly isn’t dead; the v6 upgrade this year delivered all the same features to Ionic Angular, Vue, and React. I think it’s mainly the router that needs some love-- if you check the commit history for the router, you’ll see that the core code hasn’t changed in about a year.
I think the huge advantage of Ionic and why I’m sticking with it despite the pain is that the team places great focus on running everywhere-- iOS, Android, and PWA. And the fact that you can do this with your choice of framework is really fantastic.
As for the bugs, I have found the Ionic team really responsive when posting an issue in GitHub in the cases where I can provide a sample repo to reproduce the issue. Without the sample repo, your issue is probably not going to be prioritized, but if you can show an obvious failure in the code, it will be fixed pretty quickly, much faster than with other projects I have worked with.
As the other commenter said, it is better to be specific… it sounds like you are just commenting here which doesn’t solve anything at all. Since there are probably a few developers finding success using Ionic React Router I suspect it isn’t quite as bad as you make it out to be due to your frustration in finding answers you want and need I can understand the pain.
So if you have a specific problem, with a sample project demonstrating the issue, I have found the community and the Ionic Team to be extremely responsive
Well, I did post a specific problem here. I ended up moving my state up to fix the problem.
I was also struggling with this issue. It was very discouraging to see an Ionic employee directly contradict the documentation and then be dismissive of the problem after realizing his mistake.
I was also struggling with this issue. It turns out it was caused by trying to use a Route component within a fragment. I was trying to do code-splitting with my routes, but I guess I have to use just one big file because use fragments breaks it and using multiple IonRouterOutlets breaks it.
Then my current bugs are… First, it seems if I trigger multiple re-renders from multiple useEffects loading async data, it causes the transition animation to trigger multiple times. It looks pretty jank.
And then second I wish IonBackButton had more options for manipulating the history stack, because if I use a link to switch between IonPages in IonTabBar, I want the back button to go up a level in the routes for that Tab, not to go back to the previous page.
The documentation around all of these is so unhelpful. Like for IonBackButton it says “It is smart enough to know what to render based on the mode and when to show based on the navigation stack.” Which is fine if it does what I want, but when it’s not working and I’m trying to apply some hack to fix it, I’d love something more clear than “It is smart enough to know” … And all the documentation is like this. I want to know more about what’s happening and better sample code.
I’m sure all of these problems are solvable. I’m sure I could provide a repo to reproduce these issues and after lots of discussion get some fix put in place. But it’s so many bugs, the documentation is often wrong and doesn’t get corrected, implementation details are black boxed but then I need to know them to get my things to work… Honestly I’m just not invested enough in this framework to go through the trouble.
@ptmkenny Okay though. It’s true, I am loving how simple and good looking Ionic is for PWA when it actually works. Most of my bugs are with the routing so it makes sense for me to wait for this update at least… If I have to move everything off Ionic it’s gonna be quite a pain…
Nested routes do work, but for some reason require <IonPage> as a wrapper. I made an update on that post.
Code splitting definitely works; I have it working in the app I am building on the latest release of Ionic (6.0.14).
As for transitions being triggered multiple times, I’ve avoided such issues by using react-query, <Suspense>, and <IonLoading>. Basically I load the data I need async with react-query and use <Suspense> to show an <IonLoading> component until I’m ready to do the render, which gives me nice transitions and avoids a whole lot of other kinds of errors.
As I said, I’ve found all the bugs I reported to Ionic that included a sample repo got fixed pretty quick, and the ones that didn’t have a repo attached generally got ignored. So the way forward to get fixes is to actually demonstrate the bug and file a formal issue. If all of us take a little time here and there to do so, a lot of bugs will get fixed and we’ll all be much happier using Ionic.
This is a reason that multiple hybrid app projects have gone the Flutter or React Native route.
I believe mobile devices have gotten plenty powerful to have great DOM-Based apps.
One of the things we look for in projects is how well they adapt to their core dependencies. It isn’t as though React Router 6 was a sudden surprise. There was plenty of time to update the Ionic Router. We had a similar problem with Gatsby, while our team liked it overall - we are moving to NextJS, and part of that was a lack of updating the router library. Similar to React 18 support, any lib that has a huge core dependency on React should be ready for the core releases.
Obviously, not every dependency library needs to be constantly updated. This feels like a miss and hopefully it gets addressed.
Not sure what you mean by “plenty of time to update”. React Router 6 had a beta 3 update and then no further updates from its team, as the react router team was working on an entirely different framework.
In this time, Ionic 5 was released and then Ionic 6 entered its final beta, and a couple weeks before the official Ionic 6 release, suddenly React Router 6 got an official release.
Also, when React Router 6 released, for the first half year, it didn’t have backwards compatibility. So if Ionic had updated to RR6, there would be a situation in which Ionic 5 → 6 is an easy upgrade for Angular + Vue, but React apps need to be entirely rewritten.
Well, that’s not completely true. v6 beta 8 was released on Oct 22. Once something is in Beta, it is probably a good thing to start adapting libs that depend on it to the new beta too.
React Router 6 is different, to be sure. You can see one idea for a method here:
And, no, it would not mean completely re-writing a react app. It isn’t that hard to go from React Router 5 to 6. @ionic/react-router has 23,551 weekly downloads. react-router has 8,459,164 weekly downloads. React Router v6 came out of beta 7 months ago. The fact that @ionic/react-router had a patch 4 months ago and really all significant work was 13 months ago shows that the major Ionic update wasn’t anything related with routing.
I get it though. Matching native routing animations is pretty much impossible in a PWA. I’m not sure there is another library that even tries, since it’s really only possible in Cordova/Capictor or some other DOM-based “native” app.
Still, It’s one of the most popular React libs. The fact that there seems to be no timeline or roadmap on supporting the current router code. Thus, it makes it hard to suggest to clients to adopt.
Just to be clear, I don’t speak for Ionic, but Ionic is enterprise software.
As enterprise software, it tends to be a bit more conservative in updates-- during a major version beta, updating the dependencies to beta would be a goal only if you’re reasonably confident that something stable will be released, but React Router 6 was in beta for a year and a half, which is longer than the current Ionic release cycle.
As far as the timeline and roadmap, those aren’t public, but if you have an enterprise account with Ionic I’m pretty sure they will provide you with the information. Ionic generally avoids making public commitments because they don’t want a bunch of (non-paying) users angry if they miss a deadline.
I do most of my work in Drupal, which is a similar enterprise-focused FOSS community, so I can understand some of the pressure here.
I started a lib if anyone wants to help get it polished the final bit.
@ptmkenny I can’t agree with you fully on your comment. I can see why the Ionic team probably avoided updating the router. It’s sort of a mess. That said, the testing app hasn’t been touched in ages (it still uses v5 code), so it is questionable if the team even properly tested routing with Iconic v6. That’s not a great enterprise way of doing things.
There are routing components and libs in @ionic/react that should be in @ionic/react-router. There is some challenging hoisting of state from the <IonRouterOutet> elements, wrapping components with Ionic lifecycles, etc…
To be fair to the Ionic team though. It is clear that Angular is a first-class citizen in Ionic and React is pretty new. Facebook is pretty horrible at supporting standards (like web components) and occasionally introduces questionable patterns. React has some good parts to be sure, but it is clear Iconic had to jump through some hoops to get it working with the Stencil framework.
And please, Ionic team, please take what I have here if it helps. Although, I’d honestly suggest that way more loose coupling be employed. Currently, there are places inside of @ionic/react that expect react-router to be the only routing lib. If that is the case, don’t bother creating a second repository. Minimize the amount of Context that the @ionic/react lib needs and move as many of those routing components and libs down into @ionic/react-router so that the routing lib can be changed up easier.
For instance, I just completely disregarded usingReactRouterViewStack.
I need to look over some glitchy animation areas. So far almost everything seems ok, but I have a feeling that the outlets are stacking different and because I am not wrapping <ViewLifeCycleManager> as there is no more ViewStack class, it could be that there are some edge cases where the previous page is mounting when it shouldn’t dealing with tabs.
Wanted to quickly chime in here. The team does have plans to support React Router v6. We realize support for this may be coming later than expected, but work is already under way.
In terms of rendering issues with Ionic React Router, we also have work underway to simplify and consolidate our routing integrations. Routing is the most complex piece of any framework integration that we build. The main reason is that certain routing components, such as Tabs, work very differently in mobile apps than they do in traditional web apps. This can sometimes result in strange bugs and unexpected behaviors. We hope that by simplifying and consolidating the routing integrations we can provide a consistent routing experience no matter which JS framework you are using.
We appreciate your patience as we work to tighten up these integrations. Thanks!
I can completely understand your challenge. Even when developing mobile with native, hybrid stack/tab navigation sort of sucks. But it is way harder when you are stuck using the DOM History. I’ve often wondered why the DOM never implemented sub-history or any concept to support nested navigation methods. Or why there isn’t a localized history stack for each site, allowing the mutation of the stack contents.
It would be great for the Ionic team to have a lot more navigation documentation and tutorials in general. Really break down how animation is handled in Ionic. Love hearing you are simplifying the code. It all made sense, but I agree that there are opportunities for consolidation.
In Angular and Vue, how are you handling the previous view when navigating for layering the two pages? Are you cloning the rendered DOM element? What I was messing with was storing the previous Outlet from React Router 6, but I think that might be storing the React components, which will probably re-render. Not ideal if a fresh render doesn’t match the leaving view that might have had state/dom changes.
Regarding your question re: the previous view. In Ionic Angular and Ionic Vue we keep the current view and the previous view in the DOM. I believe Ionic React tries to clone views when transitioning, but it is a bit error prone so ideally React would just follow what Angular and Vue do.
I was experimenting with Framework7. It is a little heavy for what I want and didn’t really offer more than Ionic. But, it’s router was easy to use and, overall, worked great.
After checking it out, maybe the best way is just not to use React-Router at all and roll your own.
Tanstack has a router too, TanStack Router | React Router, Solid Router, Svelte Router, Vue Router that is still in beta. There is a concept of Pending routes, and preloading routes. Maybe there is an opportunity to extend the lib for some hooks so that during a pending phase the current DOM can be cloned and the new one animated in.