Unexpected order of lifecycle-hook "mounted"
Version
3.0.6
Reproduction link
https://jsfiddle.net/q5tm4ozh/
Steps to reproduce
Just run the jsfiddle and look at the console
What is expected?
I expect that the childs mounted-hook is called before the mounted-hook of the parent, but its exactly the opposite.
What is actually happening?
The mounted-hook of the parent is called before the mounted-hook of its children.
the child components are both async components, which are still being "loaded" during the first render and will then mount after they have been loaded - at which point the parent has already been mounted. That's kind of the point with async components.
So this is expected behavior for async components
@LinusBorg
foo and bar are async components, but bar will actually be loaded only after foo was loaded.
<foo><bar></bar></foo>
foo will be loaded mounted when its loader is resolved but bar loader is only called after foo is resolved
so if it takes to load foo 5 seconds and bar 5 seconds then it will take 10 seconds in total I would think that this case could have been optimized, but I am not too versed with the internals.
Your description is correct, but also expected. The described scenario is not a realistic or common one, in my perception.
I would be hard to optimize this without breaking the - much more useful - behavior of evaluating slot content only when it's actually being used/rendered.
That is a good point. I didn't consider that this might not be a common enough use case and that
there is no way of knowing that bar is actually going to be rendered ( the slot can be conditionally rendered on foo) and foo is async so we don't have the knowledge of what it will do until it is loaded. and since rendering is lazy evaluated then this kind of optimization is not desirable
I suppose prefetching would be the way to go, for cases where we know related components needs to be loaded in a more responsive way.
@LinusBorg thank you for the feedback it was helpful