Refactor "htmx" to "fetch action"

[wxiaoguang]

The only remaining (hard) part is "templates/repo/editor/edit.tmpl", see the FIXME

By the way:

• Make "user unfollow" use basic color but not red color, indeed it is not dangerous
• Fix "org folllow" layout (use block gap instead of inline gap)

[silverwind]

One minor UX regression worth noting on templates/shared/user/profile_big_avatar.tmpl: the previous htmx version had hx-indicator="#profile-avatar-card" on the <li>, so the whole avatar card showed the loading state during a follow/unfollow request. After this refactor only the button shows loading (default data-fetch-indicator = the element itself, per common-fetch-action.ts). Trivial to preserve with data-fetch-indicator="#profile-avatar-card" on the button if the old behavior is desired.

---

This comment was written with the help of Claude Opus 4.6.

[wxiaoguang]

One minor UX regression worth noting on templates/shared/user/profile_big_avatar.tmpl: the previous htmx version had hx-indicator="#profile-avatar-card" on the <li>, so the whole avatar card showed the loading state during a follow/unfollow request. After this refactor only the button shows loading (default data-fetch-indicator = the element itself, per common-fetch-action.ts). Trivial to preserve with data-fetch-indicator="#profile-avatar-card" on the button if the old behavior is desired.

This comment was written with the help of Claude Opus 4.6.

Do you think the larger loading indicator is better than the small one on the button? Why the loading indicator should hide the whole left sidebar when "following"?

[silverwind]

I need to test, but intuitively, button loading state sounds cleaner.

[wxiaoguang]

I need to test, but intuitively, button loading state sounds cleaner.

Isn't it what I asked for many time? Please show your thoughts, don't copy & paste AI's slop.

Every time you don't read code or comment, or don't really try, I simply ask back. Isn't it wasting the time of us all?

[silverwind]

I checked that profile page button. It does not show a loading spinner because the condition "disabled" in button always evaluates to true:

https://github.com/go-gitea/gitea/blob/main/web_src/js/features/common-fetch-action.ts#L42

Not sure if the absent spinner is intentional, but keep note that that condition will be always true for these elements:

https://html.spec.whatwg.org/multipage/semantics-other.html#concept-element-disabled

If intentional, would refactor to a canElementBeDisabled(el) or similar to make the intent clear.

[wxiaoguang]

. It does not show a loading spinner because the condition "disabled" in button always evaluates to true:

It is also done intentionally, I found that showing the loading spinner is very ugly on a button, "disabled" should be the best choice in my mind.

If intentional, would refactor to a canElementBeDisabled(el) or similar to make the intent clear.

I don't see the requirement to make it more complex right now. If you introduce canElementBeDisabled, you are still not able to pass TS strict check (then need more code)

The current design is good enough and flexible enough, and it won't block future improvements (if there would be any)

[wxiaoguang]

By the way, "disabled" has been used for a long time, see 1.26 code. There is nothing new.

[silverwind]

Fine if intentional. I generally also dislike loading spinners, especially short-lived ones because they only distract. Maybe a better framework is needed to only show loading spinners when a action takes > 1 second, but that's something for later.

[wxiaoguang]

I generally also dislike loading spinners, especially short-lived ones because they only distract. Maybe a better framework is needed to only show loading spinners when a action takes > 1 second, but that's something for later.

Yes, I also agree. However, if we'd like to introduce such a framework, we also need to do more like "avoid duplicate submit" between 0s ~ 1s. That's another topic.

[silverwind]

avoid duplicate submit

Yes, like a data-loading=true.