Page MenuHomePhabricator

[WtC-M2] Replace WiKit TextArea component by Codex's
Closed, ResolvedPublic8 Estimated Story Points

Description

Problem

The Mismatch Finder's user interface was composed using a combination of Vue 2 custom components and WiKit elements, such as TextArea. The WiKit design system is now on its deprecation path, as it has been superseded by Codex, the official Wikimedia design system. The utilization of WiKit components is not recommended, and they should be replaced in order to reduce maintenance costs and ensure consistency.

Solution

We have to replace the WiKit TextArea by the Codex equivalent: cdx-text-area (See demo) in combination with cdx-field (See demo). See 'Considerations' for more details. This will take us a step closer to switching to the new design system and deprecating the old.

Screenshot 2023-09-22 at 17.16.24.png (984×1 px, 233 KB)

Considerations

There are a couple of TextArea states that are either missing or not consistent with Codex. We'll bypass them by design:

  • Replace inline loader by progress bar: The WiKit text area displays an indeterminate inline progress bar to communicate its loading state, but this is not aligned with Codex’s guidelines. We’ll show Codex's indeterminate ProgressBar on top of a read-only TextArea to communicate that the request is being processed.


  • Replace warning state by error state: In MSMF, the TextArea displays a warning when users try to submit an empty request. This state is part of the WiKit component. In Codex, the inline validation of form fields is managed (among other things) by a different element: the Field component, which at the moment doesn't provide a warning state. We’ll use Field's error message instead to facilitate the migration.
Loading stateWarning state replaced by error
loading state.png (886×1 px, 78 KB)
e1.png (886×1 px, 69 KB)
See specifications
Acceptance criteria
  • WiKit's TextArea is replaced by its Codex equivalent
  • We use Codex's Field to add a label and inline validation messages to TextArea
  • Codex's Progress bar is used to display loading state

Event Timeline

Task Breakdown Notes:

  • The task is probably not parallelizable

Potential plan of action:

  1. Create a Mismatch Finder wrapper component that combines the Relevant codex components: TextArea, Field, ProgressBar - With Vue component tests
  2. Make the component reactive to the loading state and messages, the various states are detailed in the design specs
  3. Incorporate the new wrapper component within Home.vue

Thanks for the replacement! Here's a list of issues detected in all browsers:

  1. Missing label: The TextArea/Field should still display a label that says "Please add one Item identifier per line". (This label should be announced by screen readers, but I believe that'll be the case by default).

Screenshot 2024-01-04 at 15.39.13.png (436×754 px, 36 KB)

  1. Unwanted white space under footer: When the TextArea's height is reduced to the minimum, white space appears under the Mismatch app footer.

Screenshot 2024-01-04 at 15.34.44.png (1×2 px, 175 KB)

  1. ProgressBar's width: Applying a 50% width to the bar makes sense in wider viewports, but this makes it become a bit too small below the tablet breakpoint:

Screenshot 2024-01-04 at 15.17.13.png (490×672 px, 31 KB)

Recommendation: add a media query to increase the width of the bar to 80% below the tablet breakpoint. This is sort of an arbitrary value, given that the responsive behavior of ProgressBar hasn't been defined yet (see T352844).

Hello, @Sarai-WMDE , the white space below the footer is not related to the textarea, it is an issue of the height of the page... Don't know if it makes sense to put in these changes. We had already worked on this issue but it seems like the solution wasn't bulletproof. :/

Update:
I have found the cause of the problem. It is not part of the textarea component, but part of layout.vue.

Relevant PR: https://github.com/wmde/wikidata-mismatch-finder/pull/831

The white space under the footer issue is not part of the Textarea but it solved in a different PR: https://github.com/wmde/wikidata-mismatch-finder/pull/832