POC for vue-router in Metrics Dashboard

Background

Our Dashboard is growing in complexity, while some of the complexity in state is managed by Vuex, we must also maintain a bi-directional communication with the browser bar / URL. The URLs created contains more data that communicate with the dashboard.

Here are some features have and we'll be adding moving forward:

• Time Range parameters are updated as the user interacts with charts #37908 (closed)
• We create vanity URLs based on the dashboard name #214282 (comment 344149515)
• Select non-master branches #208448 (closed)

If we continue adding features related to the URL without a specific structure, we may end up with a spaghetti of states-URLs changes.

Proposal

Nudge the monitoring dashboard in the direction of an SPA and use Vue Router as the boring solution to set it up, with Vue Router we have the following advantages:

• Switching between dashboards will not require full reload of the page.
• Expanded panel can be implemented (later) as a master-detail route.
• The router would be the SSoT for the monitoring URLs.
  • Reducing decoupling of URL between the backend (e.g. metrics link) and frontend (e.g. panel params).
• Allows for easy migrations with this backwards compatibility redirections via (*) to match old routes.

We must also act fast, as we need to provide backward compatible improvements, and accumulating them will make things more difficult.

What does this MR do?

This is (slightly) broken POC of a new "Dashboard App" that contains a single Vue Router route to kickstart the usage of the how we could start using vue-router in the monitoring app.

The goal is to show how we can start using Vue Router with few lines of code and no major refactors.

This MR is not meant to be merged, but as a starting point for discussing our architecture

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

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