Skip to content

Add coming soon tab to Package Registry list

Nick Kipling requested to merge 198524-add-frequently-requested-coming-soon-package-manager-formats-to-the-package-registry-ui into master

What does this MR do?

As per #198524 (closed), this adds the new Coming Soon tab to the Package Registry list. Please see the issue for further context.

This MR is an attempt at implementing this feature, which is relatively unique (as far as I can tell) because:

  • it should only work on GitLab.com
  • it needs to pull issues from a specific project on GitLab.com (the GitLab project itself)

I've not seen any other feature with requirements like this, so the code here is a reflection of a possible implementation that has been designed to be easily reverted and removed without (much) risk.

There are two components one component and one helpers.js file, see below:

File What does it do
packages_coming_soon.vue The main UI component which renders either a loader, the list of found issues or an empty state.
coming_soon_wrapper.js A renderless component which is responsible for making the GraphQL request for the issues, processing them and passing them to the rendering component.
helpers.js The helper methods that contains a default config and logic to process the results. There is also a method for determining if the feature is enabled or not.

FAQ:

How does this work?

The list of issues is supposed to show new package registries that are soon to be supported. This is dynamic and can change as / when work is completed, therefore the list works by fetching issues from the GitLab project which contain a particular label via a GraphQL query.

This allows members of ~"group::package" to dynamically change what is displayed in this list by managing the labels on issues.

A GraphQL request is made when clicking the Coming Soon tab and will show a loader until the data is fetched.

What does helpers.js do?

This contains a default configuration used for package and methods to process the results to determine:

  1. What workflow:: label is applied
  2. If we are currently ~"Accepting merge requests" on the issue

If either are true (or both) then these labels are displayed next to the issue.

There are some comments in the file itself to further explain how the code works.

Why not use Vuex / other?

This is pretty experimental and the issue is not thoroughly defined in how it should work. I wanted to write code that could be removed with the least amount of risk possible, so encapsulated files that sat outside of the existing Vuex store seemed like a good idea to me.

In addition, I wanted this to be portable and possibly used elsewhere outside of package. Therefore, the fetching logic is separated from the rendering logic with the use of the wrapper component.

Why use a wrapper component?

So that implementation is flexible and easily changed or modified as part of code reviews or future work.

The wrapper component has now been changed into a renderless component. It now contains the GraphQL code and will execute the query to fetch issues and pass the result onto a child component to render. Right now there is only one rendering component, but this can changed to suit other needs.

This wrapper component can be passed a custom config that could be used to change what labels the GraphQL request looks for, etc. Currently, the config options are very limited but my idea here is that the wrapper could be generic enough to be used elsewhere and whatever child you pass to it can handle any specific rendering requirements.

Switching to ApolloQuery

It turns out the wrapper component I wrote was basically performing the same functionality that the ApolloQuery component was designed to handle. As suggested, I've changed the implementation to use this component directly inside the packages_coming_soon.vue component. This reduces the amount of code and encapsulates the feature into less files, reducing the risk. This also enabled some better testing, so I feel all round more confident with this approach.

Feature Flag

There is a packages_coming_soon feature flag used for this.

Screenshots

With test issues Empty State
Screenshot_2020-04-16_at_10.42.54 Screenshot_2020-04-17_at_09.58.14

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • [-] Label as security and @ mention @gitlab-com/gl-security/appsec
  • [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • [-] Security reports checked/validated by a reviewer from the AppSec team
Edited by Nick Kipling

Merge request reports