QPage - Is it really neccessary to have QPageContainer which just offsets the dimensions?

[cyfung1031]

For QPageContainer, it is just to offset the box-model using padding values.

Indeed it can be done in QPage - giving margin values and set the box-sizing to content-box

This would increase the performance as:

• in scripting, qPageContainer is eliminated.
• in rendering, it would be faster as 1 nested container is removed.

[cyfung1031]

Suggested coding changes can refer to PR #10789

CodePen Examples
https://codepen.io/cyfung1031/pen/rNwrQgM
https://codepen.io/cyfung1031/pen/rNwrPav

[ontwikkelfabriek]

@cyfung1031

Is it really neccessary

I think the devs followed a 'known to work' design pattern/structure. As you showed it's possible to go without the separation of Q-page-container and q-page, but that could very well change in the future.

If that happens then instead of just upgrading to a new Quasar version all apps would have to introduce a q-page-container.... btw that's just my theory

[julie777]

I believe that qpagecontainer is useful as it handles the space taken by the optional header and footer by calculating and padding as appropriate. This allows qpage, (which is not strictly necessary as you can use another element instead) in the main content area to ignore the header and footer information.

I believe that this is all based on each part of layout being full window size and then padding and margins are changed to do things like deciding whether the left sidebar overlaps the title is is under it.

It could definitely be better in some cases if the page was a distinct entity so that when there was a fixed title the scrollbar for the page didn't extend to the top of the window.

[rstoenescu]

It may seem like a performance enhancement to eliminate one component, but it’s really not.
QPageContainer is needed because of all the following combined:

1. Performance - most UIs have multiple pages so the padding computations would be done each time the user navigates to a new page. The extra component cost is negligible with Vue 3 anyways.
2. Ability to correctly display page change transitions (with the Vue native transition> component) without the need of “hacks”. Won’t get into detail here because this would deserve a thread of its own by how complex it is.
3. Ease of styling on QPage. Adding a custom padding on QPage would break the inner computed one. Devland padding would need to take into account the inner one (which changes dynamically based on the other Quasar layout components).

[julie777]

After much research, I found that QLayout uses wrappers for the various parts, drawer, page in order to remove layout concerns from the code that you write. Qpagecontainer is visible because it has to be in the layout in order to have a place to inject the pages with the router.
Drawers have invisible wrappers that control show/hide fixed vs scroll with page and even automatically add a drawer scroll bar if the contents of the drawer won't fit when the drawer is fixed. The deeper you look, the more it makes sense.