Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Remove Vuetify from Studio]: Remove Vuetify Layout components

Aperta
  • Qualcosa non va?
#6,053 6 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
css, javascript
Ambito
frontend, web-dev

Direzione di ricerca

Inizia dai file shell condivisi indicati nell’issue—AppBar.vue, MainNavigationDrawer.vue, ImmersiveModalLayout.vue, FullscreenModal.vue, AppError.vue e ChannelEditAppError.vue—e rivedi il loro utilizzo del layout Vuetify. Lavora pagina per workflow, esegui le suite unit/component esistenti, svolgi il QA manuale e fornisci screenshot prima/dopo; completato significa che nessun componente di layout elencato rimane senza regressioni.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

❌ 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 #5060's existing convention, for easier QA

Excluded:

  • Other Vuetify components (buttons, forms, dialogs, data tables, menus, etc.) — tracked in separate #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.

Lingua principale
Python
Stelle
191
Fork
308
Merge medio
2g 6h
PR unite (30g)
65

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di learningequality/studio

Tutte le issue di learningequality/studio

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.