Startup.js Concept for Repository View

What does this MR do?

It is a basic POC setup for sending of REST calls as early as possible for the Vue Views that will be rendered. In first tests with the repo view I was able to save up to 500ms and this was only with the 1 or 2 REST calls (Commits + Readme). If we would be able to do the same also with GraphQL we might be able to save even more (see the waterfall). Testing locally with consistent timings is hard so mainly preliminary results.

How does it work

Generic

The idea is simply to start any REST calls (hopefully soon also GraphQL) as soon as the page is loaded to parallelize it while the JS is parsed and initialized and reduce overall rendering time. Clear goal to make it as easy as possible to define calls.

1. You define any REST endpoint URL's that should be loaded right away next to your Vue application (In this first implementation in app/views/projects/_files.html.haml). By using a new helper method add_page_startup_api_call which adds the URL to a new object
2. In the head Rails template we check if any startup URLS were defined !34713 (diffs)
3. The ruby object is converted in a script tag to JSON and initialized into a new global gl attribute named startup_calls - !34713 (diffs)
4. Those URL's are called and the specific URL startup_calls attribute is converted to an object to hold the fetch promise and the actual response to check later. !34713 (diffs)

Specific to the File Tree View

1. In the initialization of the Vue App we check if a startup call with our needed URL was defined and maybe has either a response or is still a promise
2. For the Commit Infos of the current tree - !34713 (diffs)
3. If the Readme was maybe already loaded - !34713 (diffs)

Screenshots

New Loading waterfall (REST call straight after Page Load)

HTML5 Boilerplate Old loading (Everything on screen rendered ~3600ms timestamp)

HTML5 Boilerplate New loading (Everything on screen rendered ~3100ms timestamp)

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

Closes #220511 (closed)