A minimal change to replace data calls with attr as per guidelines

[Ryuno-Ki]

Tiny step towards #18345 (comment)

This affects the manage topics on a repository. Namely the done
button once changes are made.

gitea/templates/repo/home.tmpl

Lines 48 to 49 in d9b50e4

	<a class="ui button primary" href="javascript:;" id="save_topic"
	data-link="{{.RepoLink}}/topics">{{.i18n.Tr "repo.topic.done"}}</a>

I'm unhappy with the associated template, as there is an anchor
element for something that should be a button. Since it must not be
mixed, I haven't refactored the code into a Vue component yet.

How are refactorings organised in this project?

Signed-off-by: André Jaenisch andre.jaenisch@posteo.de

[wxiaoguang]

Since it must not be mixed, I haven't refactored the code into a Vue component yet.

In my mind, there might be some options for rewriting the code into Vue:

1. All components from scratch
   • then there should be a well-designed Vue-based UI component library first
2. Re-use the Fomantic UI CSS styles, write template and JS in Vue
   • it seems the easiest way
3. Mix Fomantic UI jQuery and Vue JS
   • the problem is that Fomantic UI is a MVC framework and Vue is a MVVM framework, they don't work in the same way, it would made the mixed code very difficult to be maintained or refactored in future.

And still in my mind:

• I prefer option 1 but it requires a lot of design & plan work, the work hasn't been started yet, so not feasible at the moment.
• option 2 is used mostly in my code and existing code.
• although option 3 is discouraged, if it must be used and the code is clear and fine tuned, it should also work .....

[wxiaoguang]

About the mixed code, you can have a look at repo-search:

https://github.com/go-gitea/gitea/blob/main/web_src/js/components/DashboardRepoList.js
https://github.com/go-gitea/gitea/blob/main/templates/user/dashboard/repolist.tmpl

I do not think it's a good practice to use Vue.

---

The development guidelines are always open (actually, most of them were written recently), if you have ideas about how to make the code base more healthy and maintainable, please suggest 🙏

[wxiaoguang]

Please help to review #19901

• Update frontend guideline #19901

[Ryuno-Ki]

I feel like this should be another issue (since discussion tab is disabled in this repo), but allow me to reply here for the time being:

In my mind, there might be some options for rewriting the code into Vue:

1. All components from scratch
   
   * then there should be a well-designed Vue-based UI component library first

https://storybook.js.org/ is becoming industry standard. How do you deal with disabled JavaScript in these cases? I've read elsewhere, that Gitea wants to be able to cater for these cases (and I assume, you don't want to run Server-Side Rendering).

2. Re-use the Fomantic UI CSS styles, write template and JS in Vue
   
   * it seems the easiest way

I would suggest this for now, too. With the option to extract LESS files from Fomantic once the rewrite is complete (to drop the dependency entirely).

3. Mix Fomantic UI jQuery and Vue JS
   
   * the problem is that Fomantic UI is a MVC  framework and Vue is a MVVM framework, they don't work in the same way, it would made the mixed code very difficult to be maintained or refactored in future.

I agree. It will be a lot of work to detangle. Perhaps some meta-issue could be tracked with a task list listing all files and PRs that reference their refactor. As I mentioned in that chat, the sheer number of open PRs make me nervous that I would duplicate work.

And still in my mind:

* I prefer option 1 but it requires a lot of design & plan work, the work hasn't been started yet, so not feasible at the moment.

* option 2 is used mostly in my code and existing code.

* although option 3 is discouraged, if it must be used and the code is clear and fine tuned, it should also work .....

I would suggest going with option 2 until the Fomantic dependency can be dropped. Looking at fomantic/Fomantic-UI#319 (comment) there is a transition planned to TypeScript and SASS (SASS is more popular then LESS, TypeScript has a learning curve).

If option 3 is applied, perhaps open an issue to follow-up with a refactoring (or note that in the meta issue).

I came across certain elements, that would make a good fit for a component.
If we spend the time to configure Storybook, then components could be defined there and once „approved” introduced into the codebase. Be aware, that npm audit has several known issues with Storybook.
Let me know how to proceed here.

(I'm okay if you copy these conversations into a new issue and refernce this PR there)

[wxiaoguang]

There are discussions (as old as back to 2019)

• UI Update discussion #5937

The Gitea UI problem is really a long story .....