Repository navigation
[Remove Vuetify from Studio]: Remove Vuetify Layout components #6053
Description
❌ 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, andVContentwith 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?
- Shared navigation & app shell elements first —
AppBar.vue,MainNavigationDrawer.vue,ImmersiveModalLayout.vue,FullscreenModal.vue,AppError.vue,ChannelEditAppError.vuerender 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. - At least one issue for a single layout with without wrapping or grid behavior should be able to swap directly into plain divs/flexbox.
- 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/VContenthas 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.
Activity
MisRob commentedon Jul 26, 2026
Hi hi☺️
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)
AppBar+MainNavigationDrawerjust replace withStudioNavigationFullscreenModalwithStudioImmersiveModal(may be good to check ifStudioImmersiveModalalready has all features it needs at all places though if you will be replacing it everywhere at once)AppErrorwithStudioAppError(same check)After that's done, just remove☺️
AppBar, ... and all will be goodChannelEditAppError, for the most part it's already built aroundStudioAppError, perhaps there will be just some cleanup ofVContentand toolbarImmersiveModalLayoutcan be removed. I think we already refactored all places where it was used and I didn't get to clean it up.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
StudioPagewill be the way to go, sometime ratherKCardGrid(imagine refactoringVLayoutetc. 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 introducingKCard+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 commentedon Jul 26, 2026
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.vtushar06 commentedon Jul 27, 2026
Hey @marcellamaki @MisRob, let me know if I may help in any place for this tracking issue :)
marcellamaki commentedon Jul 27, 2026
Yes, I definitely agree @MisRob , and my goal is definitely not to do a component-to-component refactor at all (so I appreciate the feedback that is not clear here, and will edit the issue accordingly this week to try to make my thinking a bit clearer). Rather my plan is to write up sub-issues for pages comprehensively and make all the changes that are needed in the layouts of each, mainly with CSS, bringing in existing studio components, and adjust the styles and divs as needed to implement successfully and maintain all of the interactions without regressions, and try to have very few visual regressions as well. There may be common approaches to these (hopefully, that will allow us possibly to use some shared patterns) but a component swap I don't think will work easily or be the best choice in most (if any) cases and adds a lot of QA difficulty as well.
As for starting with the navigation elements, (as I mention, I will edit to make this clearer in the issue description as well as in the sub issues) it is rather that I would like us to make these replacements you describe early, and pick a page or two to do an additional "replacement" with, where the underlying page is mostly straightforward, and see if once we do the replacement(s) across an entire page or workflow, including these shared components, are there things we did not account for 🙂 as once in a while that happens. I don't want anyone to re-re-factor these components 😁
MisRob commentedon Jul 28, 2026
@marcellamaki okay good luck :) it sounded as touching particularly on few areas that are half-way through and Studio now has two mixed approaches due to gradual piecing out of some larger components that are still used from few remaining places, or are not used at all anymore and can be removed. So wanted to reach out to make sure there's awareness about it ~ that was the main point. I will also add a
ChannelItem~ that's a biggie ~ originally used from many places (80% of its inner logic is obsolete but there was no need to clean it up since it was going to be removed ~ it just still lives in the codebase because it's used from couple remaining places). And someStudio...components are only half-ready because they were created for a feature at a particular place, with a plan to add new logic to them if needed as they are gradually introduced to more and more places.Minor side note category ~ yes I think this part I followed, it's just that layout is closely interrelated with what's inside it so taking it as a 'separate thing' is a different mental model. I think I shouldn't call it component-by-component. Better way to describe the nuance would be refactoring area as a whole (example in this particular context: layout + its content) vs refactoring selected parts (layout only) of an area. You will see how it goes, stress test is a nice idea :) Even with the first approach, here & there I had do layout separately on some occasions due to some specific factors. I reached mostly because I worried about half-done state part and that's sorted out, this part was only to clarify what you quoted from the epic.
@vtushar06 Good to hear from you! I hope you're well. It will be best to coordinate with Marcella, I'm just sticking my nose here and there :)
vtushar06 commentedon Jul 28, 2026
Yeah Definitely @MisRob, please do me ping if I may help @marcellamaki.