Migrate away from select2 in app/assets/javascripts/project_select.js
The app/assets/javascripts/project_select.js
script initializes select2
instances on all .ajax-project-select
selectors. The selector is being applied by the SelectsHelper#project_select_tag
method which we currently call in a few views:
View | Preview |
---|---|
app/views/clusters/clusters/_advanced_settings.html.haml#L22 (Sample GDK link), Displays all the projects in the group |
From this discussion, we know that this feature is deprecated and is slated for removal at the end of Feb. 2023 |
app/views/shared/_new_project_item_select.html.haml#L5 (Sample GDK link), Displays all the projects in the instance |
|
ee/app/views/admin/application_settings/_templates.html.haml#L20 (Sample GDK link), Displays all the projects in the instance |
|
ee/app/views/groups/_insights.html.haml#L26 (Sample GDK link), Displays all the projects in the group |
|
ee/app/views/groups/_templates_setting.html.haml#L20 (Sample GDK link), Displays all the projects in the group |
As part of this issue, we'd like to migrate those selectors away from select2
.
In all cases, we are rendering project selectors with async filtering capability where a single selection is supported.
Note that the instances that have the simple_filter
option enabled are being handled by the app/assets/javascripts/project_select.js
script exclusively. The Issue dashboard > Select project to create issue selector is the only occurrence that does not have the option enabled. This one gets a bit of extra handling from the app/assets/javascripts/project_select_combo_button.js
script. At first glance, it looks like all this script does is programatically open select2
's dropdown. In the current implementation, the script also loads the select2
library, which doesn't have any effect because app/assets/javascripts/project_select.js
already loads all the necessary modules. It is possible that ProjectSelectComboButton
was meant to be used as a standalone class, outside of app/assets/javascripts/project_select.js
, but it isn't at the moment, which makes our lives a bit easier for this migration.
We currently have several Vue project selectors implementations in the codebase (search for projects-dropdown
for example (1, 2, 3, 4)). None of these seems to have been thought as a shared component.
We do have the app/assets/javascripts/vue_shared/components/project_selector/project_selector.vue
component, but this one does not act as a dropdown, which is what we'd need here.
It would be great to take advantage of this migration to come up with a component that could be easily reused wherever we need a project selector in the product. We would likely want to create a wrapper around GlListbox
.
Implementation plan
-
Create a shared project selector component based off GlListbox
. !108807 (merged) -
Leverage the new component in affected views. -
app/views/clusters/clusters/_advanced_settings.html.haml
!109543 (merged) -
ee/app/views/admin/application_settings/_templates.html.haml
!109543 (merged) -
ee/app/views/groups/_insights.html.haml
!109543 (merged) -
ee/app/views/groups/_templates_setting.html.haml
!108807 (merged) -
ee/app/views/groups/_analytics_dashboards.html.haml
#388248 (closed)
-
-
Adjust and leverage the new-issue-dropdown
component to migrateapp/views/shared/_new_project_item_select.html.haml
(!109149 (merged))-
app/views/dashboard/issues.html.haml
: the instance-level issues dashboard !109260 (merged). -
app/views/dashboard/merge_requests.html.haml
: instance-level merge requests dashboard !109868 (diffs) -
app/views/dashboard/milestones/index.html.haml
: instance-level milestones dashboard !109868 (diffs) -
app/views/groups/merge_requests.html.haml
: groups' merge requests list !109868 (diffs) -
app/views/shared/empty_states/_issues.html.haml
: a generic empty state for issues lists !109340 (merged). -
app/views/shared/empty_states/_merge_requests.html.haml
: a generic empty state for merge requests lists !109340 (merged).
-
- Subsequent cleanups will be done as part of #374520 (closed).