Use frontend fetch for branch dropdown component

[HesterG]

• Send request to get branch/tag list, use loading icon when waiting for response.

• Only fetch when the first time branch/tag list shows.

• For backend, removed assignment to ctx.Data["Branches"] and ctx.Data["Tags"] from context/repo.go and passed these data wherever needed.

• Changed some v-if to v-show and used native svg as mentioned in Use frontend fetch for branch dropdown component  #25719 (comment) to improve perfomance when there are a lot of branches.

• Places Used the dropdown component:

  Repo Home Page

  

  Commits Page

  

  Specific commit -> operations -> cherry-pick

  

  Release Page

  

• Demo

  Untitled.mov

• Note:

  UI of dropdown menu could be improved in another PR as it should apply to more dropdown menus.

Fix #14180

[delvh]

Should we perhaps cache the result?
So that we only query it once instead of whenever the user opens the selector?

[silverwind]

I guess if we do caching, we should do it in a fetch wrapper shared for all fetches, and likely opt-in per consumer.

Ideally, I'd like to see a swr-like caching strategy, but it must not be tied to any framework like Vue.

[HesterG]

For the filter step, I did some tests trying to figure out why sometimes the input get stuck, and I found that if use native svg instead of svg-icon component for the scrolling menu like in d56f5c0, the input change will respond faster:

I am wondering if this is a proper way to improve this component (change svg-component to native one).

Demo (At the end of the following demos, I was deleting input at a constant speed, but the one with svg-icon component got stuck for about 2 - 3 seconds before deletion happened)

use svg-icon component:

Untitled.mov

use native svg:

svg.mov

[wxiaoguang]

1. You need to do some profiling to figure out the key point
2. You can use "v-show" instead of "v-if" to avoid re-creating so many Vue components.

[HesterG]

I have done the profiling, and looks like the stuck time do come from vue update function if using the component:

Use svg-component, last two keydown takes 1.7s and 2.9s respectively, and the function that takes most of the time is update function from vue.

contexts of the update function:

Use native svg, last two keydown takes 194ms and 403ms respectively

[HesterG]

Updated description and the PR is ready for review now.

[silverwind]

Use svg-component, last two keydown takes 1.7s and 2.9s respectively, and the function that takes most of the time is update function from vue.

I think this does highlight a inefficiency in the svg-icon component. In React, I would wrap the component in memo, so that it won't re-render until its props change. Does Vue have something similar?

BTW, which solution did you settle on here?

[silverwind]

Now I guess the real question is why svg-icon takes so much processing time. Shouldn't vue components skip the render if all props are shallow-equal to the previous render, or is such behaviour opt-in like in React?

There appears to be v-memo and v-once, but they do seem unsuitable because they have to be set on a parent node, so those would be rather inflexible.

[HesterG]

BTW, which solution did you settle on here?

Now I used native svg instead of svg-icon component, I am not sure how to improve this if using svg-icon component.

[silverwind]

I think we need a better solution because if that octicon changes, this icon will not update if you embed it like that. Also, if we manage to fix svg-icon performance, all vue components will benefit.

How to reproduce the performance issue? Just type into the branch dropdown with many branches present?

[wxiaoguang]

To reproduce: prepare thousands of branches

Possible solutions:

1. symbol + use
2. v-html
3. virtual list

[wxiaoguang]

The merge is incorrect. It loses some fixes from #25875

[HesterG]

Done in 0ec8fd5

[wxiaoguang]

Away from keyboard at the moment, feel free to dismiss my request change

[wxiaoguang]

dismiss request change