[Remove Vuetify from Studio] Content Library Catalog - Frequently asked questions page
🙂 Looking for an issue? Welcome! This issue is open for contribution. If this is the first time you’re requesting an issue, please:
- Read Contributing guidelines carefully. Pay extra attention to Using generative AI. Pull requests and comments that don’t follow the guidelines won’t be answered.
- Confirm that you’ve read the guidelines in your comment.
Sub-issue of https://github.com/learningequality/studio/issues/5060.
Complexity: Medium
Summary
Remove Vuetify from the Frequently asked questions page in Channels > Content Library.
VContainer, VCard..., VExpansionPanel... and ActionLink built with several Vuetify components, are currently used.
Remove these dependencies on Vuetify in this specific location by:
- [ ] Replace
ActionLinkwith the most suitable KDS button or link components - [ ] Remove
VContainerandVCard...in favor of custom styles - [ ] Create a new
shared/views/StudioAccordion/andshared/views/StudioAccordionItemand replaceVExpansionPanel...by them-
[ ] For a11y,
StudioAccordion...should fully comply to APG Accordion Pattern - both Keyboard Interaction and WAI-ARIA section -
[ ] Renders arrow up/down by default, takes care of transitions
-
[ ] Accordion item can be also open programatically (needed for this What is a channel click interaction)
-
Even though
StudioAccordion...will differ in some aspects due to the above requirements, you may find some useful code in Kolibri'sAccordion(source) andAccordionItem(source)
-
Ensure that all interactions are functional as before. Do not modify ActionLink. Do not refactor any other areas of the codebase.
How to get there
- Login as
[email protected]with passworda - Go to Channels > Content Library
- Click Frequently asked questions in the side panel
Guidance
- Find detailed guidance with many code examples in KDS documentation
- Read the project for more useful references
Out of Scope
- Do not modify
ActionLink - Do not refactor any other areas of the codebase
Expected UI/UX changes
- Minor visual differences naturally stemming from the use of KDS
Acceptance criteria
These are general acceptance criteria for the project. For each sub-issue, consider which are relevant.
General
- [ ] The specification above is followed.
- [ ] Except for "Expected UI/UX changes," there are no functional or visual differences in user experience.
- [ ] There are no
::v-deepor/deep/selectors. - [ ] All user interactions are manually tested with no regressions.
- [ ] Pull request includes screenshots.
a11y and i18n
See the project's "Guidance" for useful references.
- [ ] Implementation meets a11y standards
- [ ] All components are LTR and RTL compliant (preview with
pnpm run devserversince:hotdoesn't render RTL properly) - [ ] All user-facing strings are translated properly
- [ ] The
notranslateclass been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. user-generated text) - [ ] Mobile experience is reasonable
Unit tests
- [ ] If there is a unit test suite already, it is meaningfully updated (even if tests don't fail)
- [ ] If there is no unit test suite, a new one is created. Do not use obsolete
@vue/test-utilsapproach. Instead, use@testing-library/vue(Vue Testing Library).
Reserved for @yeshwanth235 - if still interested.
Hi @MisRob I would like to work on this issue. please assign this to me
Thank you @yeshwanth235, let us know here if you had any questions.
is this issue still open.. i would like to work on it...
Hii @anshrajput428, can you please follow contributing guidelines and refer this guidance will help maintainers too.