[go: up one dir, main page]
Skip to content

Improve the way the frontend makes/updates/retrieves URLs

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

This issue is specifically in reference to this thread. However, the right approach here may be a system-wide change to the way we build URLs.

Improvements

Right now, I don't know of a definitive way to source all URLs on the frontend.

Some endpoints return some URLs, but not all of them return every URL.

In this specific case, three URLs in state are being updated with a regular expression to replace one SHA with a new SHA.
This works, but it's not particularly graceful or reusable.

In this specific case, it would be nice if (ordered in descending order of niceness):

  1. The frontend was seeded with a list of every possible URL (API and view) and a set of rules for data interpolation, which would necessarily mean a hypothetical frontend URLBuilder utility could always create the correct URL, whether it's for an API endpoint or a different view.
  2. The API "always" returned a bunch of extra URLs, like neighbor information for MR Commits, but globally applied (e.g. URLs for everything).
  3. This particular endpoint (the diffs.json and diffs_batch.json) returned the correct neighbor URLs in addition to just the [next|prev]_commit_id.
  4. The URL manipulation was centralized somewhere like url_utilities.swapAllCommitShasInUrl( old, new )

Risks

Given the potential open-ended nature of the fix here, there are a number of possible risk levels:

  1. This is the highest risk initially with an extremely low risk once completed. A fully seeded and global URLBuilder would touch virtually every feature and page of GitLab.com. However, once completed, such a utility would practically eliminate the possibility of broken URLs, and updates would be trivial changes.
  2. This is practically as impactful, and has a larger potential for variance. If each endpoint is responsible for returning it's own collection of URLs (like neighbors, canonical, whatever we can think of), it's more likely that the implementation may not be complete. Of course, each endpoint could be forced to adhere to strict REST protocol, but that kind of stinks.
  3. This is a fairly low-risk change as it only affects this particular endpoint, and it's not modifying existing return values (although I might suggest making [prev|next]_commit_id an object with a structure like { "id": [original string value], "url": [new URL value] }, which would change an existing (brand new) return value)
  4. This is the easiest and lowest initial risk solution, but doesn't actually solve the problem of ad hoc frontend URL manipulation. It's also only the lowest initial risk, because all of the risk of "randomly" doing string replacements of URLs is still there, it's just abstracted elsewhere. This may even be higher risk because it's "out of sight" in a helper.

Involved components

app/assets/javascripts/diffs/store/actions.js

Optional: Intended side effects

(Desired) The frontend has a single way of generating every known URL.

(Required) The frontend has a way to get the canonical "next commit" and "previous commit" URLs without manually replacing commit SHAs in strings.

Optional: Missing test coverage

Current coverage should be sufficient at the moment, but that depends on the approach we take to correcting this.

(For example, a global frontend URLBuilder would need a significant new suite of tests.

Edited by 🤖 GitLab Bot 🤖