Open
Description
🙂 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 #5060.
Complexity: Low
Summary
Remove Vuetify from 'Request more space' form error banner in Settings > Storage.
shared/views/Banner
that is built with Vuetify components is used for the banner. To remove this dependency from Storage/RequestForm
, create a new shared/views/StudioBanner
component that doesn't use Vuetify. Then use StudioBanner
in Storage/RequestForm
instead of Banner
. Do not modifify shared/views/Banner
.
StudioBanner
requirements
- Expected usage example:
// RequestForm.vue
<StudioBanner
v-if="Boolean(errorCount())"
error
>
{{ errorText() }}
</StudioBanner>
- Interface and implementation doesn't map exactly to that of
Banner
, and is limited only to logic that is needed for the request form - KDS theme
palette.red.v_100
is used for red background color - Dynamic error display is preserved: If the banner is showing 9 errors, and then one of them is fixed, the banner immediatelly shows there is 8 errors, even before re-submitting the form.
How to get there
- Login as
[email protected]
with passworda
- Go to Settings > Storage
- In 'Request more space' section, click 'Open form' button
- Submit the form without filling required fields
Guidance
- Read the project this issue is part of
Out of Scope
- Do not refactor any other areas of the codebase
- Do not modify
Banner
- Do not migrate all
Banner
logic toStudioBanner
. Focus on areas that are needed for this particular place and as specified above.
Expected UI/UX changes
- Minor visual differences naturally stemming from the use of KDS
- Very slightly different shade of red
Acceptance criteria
General
- The specification above is followed.
- Except for "Expected UI/UX changes," there are no functional or visual differences in user experience.
- 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
- All user-facing strings are translated properly
- The
notranslate
class 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