[Remove Vuetify from Studio]: Remove Vuetify Layout components

[marcellamaki]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Overview

Studio's frontend still uses Vuetify's page layout (VContainer, VLayout, VFlex, VSpacer, VContent) in 56 of 328 .vue files, spanning channelEdit, shared/common UI elements, channelList, and administration. This tracking issue coordinates replacing these components with <divs>s and plain CSS (using either flexbox or CSS grid as needed), as part of #5060.

Prior #5060 sub-issues in these same areas were specifically scoped to buttons, forms, dialogs, and similar individual components, with layout staying out of scope.

Scope

Included:

• Replacing VContainer, VLayout, VFlex, VSpacer, and VContent with plain CSS (regular styles and/or flexbox by default, CSS grid where the layout requires true grid behavior) across all files
• Work organized and submitted per page/workflow (not per component), matching Open-Source Community Project: Remove Vuetify from Studio in favor of Kolibri Design System #5060's existing convention, for easier QA

Excluded:

• Other Vuetify components (buttons, forms, dialogs, data tables, menus, etc.) — tracked in separate Open-Source Community Project: Remove Vuetify from Studio in favor of Kolibri Design System #5060 sub-issues
• settings — already fully migrated, no remaining usage
• Component update and replacement that is already tracked in other parts of the project that resolves these issues incidentally
• Creating new Studio or KDS wrapper/replacement components to solve this problem — this work is not intended to introduce new KDS components or vendor Vuetify components. If that comes up as the true best solution for a given scenario, it needs input from Marcella, Richard, and likely Alex before moving ahead.

Strategy

We will start with a few issues that are intended to stress-test particular areas of the approach: (1) does the page-by-page approach still make sense here? (2) does the overall approach for css/flexbox work and are there surprises that pop up?

1. Shared navigation & app shell elements first — AppBar.vue, MainNavigationDrawer.vue, ImmersiveModalLayout.vue, FullscreenModal.vue, AppError.vue, ChannelEditAppError.vue render on every page, so it will gives us a chance to test the div/flexbox swap here and check how the approach works for RTL, sticky headers, and responsive behavior in a fairly straightfowrad way.
2. At least one issue for a single layout with without wrapping or grid behavior should be able to swap directly into plain divs/flexbox.
3. Try out replacing a more complex page with CSS grid and see what works and what doesn't, what headaches we didn't anticipate (maybe CompletionOptions/index.vue)

Sequencing and complexity estimates from the pilot batch inform how the remaining files are grouped into subsequent task issues.

Testing Requirements

• Existing unit/component test suites pass
• No behavioral regressions, and minimal* visual regression (* yes this is subjective, some of it will need to be case by case in order to be practical)
• Pull requests include before/after screenshots (or recordings) of the affected page/workflow
• The PR author and reviewer/approver must both perform manual QA of the affected workflow before merge — the QA team cannot test until changes land in unstable

Acceptance Criteria

• All VContainer/VLayout/VFlex/VSpacer/VContent has been removed and replaced
• No functional or visual regressions beyond what's explicitly noted as acceptable

AI usage

Used Claude to survey Vuetify layout-primitive usage across the codebase (file counts, per-file complexity estimates, and workflow groupings) and to draft this issue. Honestly...re-wrote almost the entire issue after.

[MisRob]

Hi hi ☺️

Shared navigation & app shell elements first — AppBar.vue, MainNavigationDrawer.vue, ImmersiveModalLayout.vue, FullscreenModal.vue, AppError.vue, ChannelEditAppError.vue render on every page, so it will gives us a chance to test the div/flexbox swap here...

This note is what made me to decide to click 'Comment' (after some hesitation about if I'm just falling into the 'making-myself-important' pit 😆 ). Taking into account all kinds of previous contexts & what we chatted about throughout the project, I intuit that some parts of the hand-off didn't come through and if that's the case, apologies 🤗 Or if I am missing something & there are some reasons after all, dismiss. Just couldn't think of any rationale myself ~ since there is no need to spend any time at all refactoring these components in any way. For all of them, there already exist direct & ready replacements that can be used right away (which completely removes the need for refactoring not only of their layout, but anything in their insides)

• The whole AppBar + MainNavigationDrawer just replace with StudioNavigation
• FullscreenModal with StudioImmersiveModal (may be good to check if StudioImmersiveModal already has all features it needs at all places though if you will be replacing it everywhere at once)
• AppError with StudioAppError (same check)

After that's done, just remove AppBar, ... and all will be good ☺️

• ChannelEditAppError, for the most part it's already built around StudioAppError, perhaps there will be just some cleanup of VContent and toolbar

• ImmersiveModalLayout can be removed. I think we already refactored all places where it was used and I didn't get to clean it up.

---

We will start with a few issues that are intended to stress-test particular areas of the approach: (1) does the page-by-page approach still make sense here? (2) does the overall approach for css/flexbox work and are there surprises that pop up?

Work organized and submitted per page/workflow (not per component), matching #5060 existing convention, for easier QA

As for (1), there's nuance ~ what you describe seems like actually quite a different strategy than page-by-page/user area-by-area. Sounds a bit more like a return to component-to-component with QA/implementation scoped to a page. The original strategy just takes a page or quite ofter rather a page area (from user-point-of-view) and refactors it as whole rather than just a subset of components (with the big exception of button due to re-theming plans). Not that it would always go so cleanly (e.g. some areas or components could be blocked at a time) ~ more as a guiding principle.

As for (2), in lots of cases plain CSS should work for layout, but won't always be possible ~ it depends on the surrounding context. Sometimes StudioPage will be the way to go, sometime rather KCardGrid (imagine refactoring VLayout etc. with plain CSS while keeping Vuetify card in the grid now, just to, as part of a future task having to remove this plain CSS when introducing KCard + KCargGrid). And sometimes layout components can be simply removed because they're not needed in non-Vuetify context.

I think component-to-component-like will be a little more difficult for planning due to its working rather with internal structure than user experience and also the loss of surrounding context, and for QA due to the need for more QA passes on a page. Ultimately it depends what works for you at this point of the project ~ I only wish it all goes smoothly no matter of strategy or any technicality ☺️

Some additional layout-related areas that came to my mind as I was thinking ~ integration of layout with offline popup bar and re-organization of layout in print mode.

[MisRob]

Also, particularly for shared components but in general, for future plans I should mention that quite often component refactor can't be done 1:1 (KDS and also some Studio... components don't map strictly to Vuetify) It ties a bit back into scoping refactor based simply on user-point-of-view rather than digging deep into Vuetify files and all the intricate connections between them :) Again not saying that it can't be approached differently, it can ~ at the very minimum this is historical context to keep in mind because there's lots of components already ready that won't map 1:1 from internal project structure point of view.