VIvially·Oct 16, 2019
Thanks a lot for taking the time to provide some feedback.
> 1. Not sure about that, but the default is that it pushes to the stack. Isn't this what anyone would expect?
If you assume the stacked navigation model is the right model, then yes, I guess pushing pages to the stack is a good default behavior.
However, I'm not completely sold on the stacked navigation concept in general. Let's take GitHub as an example and try to think how the default Ionic behavior of pushing pages on the stack would apply there.
1. You navigate to the homepage. Stack: [homepage]
2. You click on a link to open a repository. Stack: [homepage, repository]
3. You click on the issues tab of that repository. Stack: [homepage, repository, issues]
4. You open a particular issue. Stack: [homepage, repository, issues, issue#1]
Obviously this is not very scalable as you
Read the rest
now already have 4 full-blown pages in your stack that are eating away resources (DOM nodes, more change detection computation, etc). So in order to fix it, you now need to decide which pages should be pushed on the stack and which ones are replacing old ones. And then, as your app grows, you also start hitting some edge cases in the Ionic stacked navigation implementation (e.g.: https://github.com/ionic-team/ionic/issues/18197). And at that point you start questioning whether this whole stacked navigation is actually worth it.
> 2. Are you sure that Chrome records the number of currently existing nodes or the number of nodes created?
I've been using the Chrome DOM Nodes counter in the past and in my experience it's been 100% reliable (at least for the use-case that I mentioned in that issue). What I did notice is that the baseline count fluctuates (e.g.: refreshing the same HTML page sometimes gives you a different _baseline_ counter after each refresh; not sure what that's about). But the difference between the initial baseline count and the resulting count always reflects the DOM manipulations performed, so I think it's a good tool for identifying these kind of leaks. However, you might want to spam the "Collect garbage" button (found in the Performance tab) after performing these kind of tests as there's a chance the DOM node was correctly destroyed but it just wasn't collected by the garbage collector (and that's why it's still reported in the DOM Nodes count).
> 3. I use Canvas inside an Ionic app. If you render your Canvas at the right point of your component lifecycle, it works just fine.
Completely agree. Once you find the right hook everything seems to work as expected. However, I feel like Ionic doesn't provide enough hooks for this, and the introduction of Stencil in Ionic 4 only made things worse (actually this started affecting us only after migrating to Ionic 4).
To give you an example, let's say you have this DOM structure:
<ion-content>
<ion-grid>
<ion-row>
<ion-col>
<ion-card>
<my-canvas-component />
</ion-card>
</ion-col>
</ion-row>
</ion-grid>
</ion-content>
In one particular instance we noticed that the <my-canvas-component> had to wait for the `<ion-col>` component to be ready (using the barely documented componentOnReady stencil method) before its size was "stable". Which makes it almost impossible to create a reusable `<my-canvas-component>` that works everywhere, because it can't know in advance in which DOM tree it's going to be placed.
> 4. Haven't observed this.
The easiest way to test this is to start a plain Angular project and an Ionic project and do a edit/build/reload cycle. Obviously, it depends on hardware and you need to try match the dependencies as closely as possible, but what I noticed is that the plain Angular project is noticeably faster.
> Instead of using Ionic 4 (I have an app made with Ionic 3), I switched to Stencil with @ionic/core. This gives me very fine-grained control over everything.
That's interesting, thanks. We may give that a try.