Draft: Read sidebar assignees from the store in autocomplete

Miguel Rinconrequested to merge
623999-autocomplete-read-sidebar-store into master

What does this MR do and why?

@ autocomplete filters its member list by the current assignees and reviewers:

  • /assign @ hides the current assignees, and /unassign @ lists only them.
  • /assign_reviewer @ and /unassign_reviewer @ do the same for reviewers.

On pages with the legacy issuable sidebar, it reads the assignees from SidebarMediator.singleton.store:

  • gfm_auto_complete.js reads store.assignees.
  • content_editor.vue passes the mediator to autocomplete_helper.js, which reads store.assignees and store.reviewers.

Both only need the store. This MR makes them read SidebarStore.singleton directly, and passes the store to the content editor as sidebarStore.

Why

The Vue 3 loader builds a module twice when Vue 2 and Vue 3 code both reach it. Each copy then has its own static singleton field.

  • sidebar_mediator.js reaches Vue, so it gets two copies. When the MR page runs on Vue 3, the page sets the field on the Vue 3 copy, and a Vue 2 gfm_auto_complete reads its own copy, which is still null. Then /unassign @ lists nobody, and /assign @ offers the current assignees again, with no error.
  • sidebar_store.js imports no Vue, so the loader builds it once, and its own singleton field is shared.

After this MR, only the page code that mounts the sidebar imports sidebar_mediator.js: sidebar_bundle.js, on the MR page and the incident page.

SidebarStore.singleton is the same object as SidebarMediator.singleton.store, because the mediator creates the store with new Store(options), and that returns the singleton. So the behaviour does not change.

Context

This came up in the review of !262801 (merged), which shares page-wide state between Vue 2 and Vue 3 copies. That MR keeps SidebarMediator.singleton shared through pageSingleton. With this MR, autocomplete no longer needs it. When both MRs are merged, the mediator and service can go back to their code on master.

This MR does not depend on !262801 (merged), and targets master.

How to set up and validate locally

  1. Open a merge request with assignees.
  2. In a comment, type /unassign @. Only the current assignees are listed.
  3. In a comment, type /assign @. The current assignees are not listed.
  4. Switch the comment to the rich text editor, and repeat both steps.

Local checks run, on Vue 2 and with VUE_VERSION=3: 228 suites passed in each lane.

  • spec/frontend/content_editor
  • spec/frontend/gfm_auto_complete_spec.js, ee/spec/frontend/gfm_auto_complete_spec.js
  • spec/frontend/sidebar

Screenshots

/unassign @ in a comment on the MR page lists only the current assignee, before and after this MR:

Before (56681b5d) After (2a075a02)
before after
How the screenshots were taken
  • I ran a temporary feature spec in GDK. It is not committed.
  • Before: the merge-base 56681b5d. After: the MR head 2a075a02.
  • The MR has one assignee, ada_assignee. The project has another member, otto_other.
  • User path:
    1. Open the MR.
    2. In the comment box, type /unassign @.
  • The spec also checks that otto_other is not listed. It passed on both commits.
  • Full page, light mode.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

References

  • Found in the review of !262801 (merged), which shares page-wide state between Vue 2 and Vue 3 copies
  • Part of #623999 — Vue 3 migration of global bundles and main
Edited by Miguel Rincon

Merge request reports