Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.gitea.com/contributing/guidelines-frontend below:

Guidelines for Frontend Development | Gitea Documentation

Gitea uses Fomantic-UI (based on jQuery) and Vue3 for its frontend.

The HTML pages are rendered by Go HTML Template.

The source files can be found in the following directories:

• CSS styles: web_src/css/
• JavaScript files: web_src/js/
• Vue components: web_src/js/components/
• Go HTML templates: templates/

We recommend Google HTML/CSS Style Guide and Google JavaScript Style Guide

1. Every feature (Fomantic-UI/jQuery module) should be put in separate files/directories.
2. HTML ids and classes should use kebab-case, it's preferred to contain 2-3 feature related keywords.
3. HTML ids and classes used in JavaScript should be unique for the whole project, and should contain 2-3 feature related keywords. We recommend to use the js- prefix for classes that are only used in JavaScript.
4. CSS styling for classes provided by frameworks should not be overwritten. Always use new class names with 2-3 feature related keywords to overwrite framework styles. Gitea's helper CSS classes in helpers.less could be helpful.
5. The backend can pass complex data to the frontend by using ctx.PageData["myModuleData"] = map[]{}, but do not expose whole models to the frontend to avoid leaking sensitive data.
6. Simple pages and SEO-related pages use Go HTML Template render to generate static Fomantic-UI HTML output. Complex pages can use Vue3.
7. Clarify variable types, prefer elem.disabled = true instead of elem.setAttribute('disabled', 'anything'), prefer $el.prop('checked', var === 'yes') instead of $el.prop('checked', var).
8. Use semantic elements, prefer <button class="ui button"> instead of <div class="ui button">.
9. Avoid unnecessary !important in CSS, add comments to explain why it's necessary if it can't be avoided.
10. Avoid mixing different events in one event listener, prefer to use individual event listeners for every event.
11. Custom event names are recommended to use ce- prefix.
12. Prefer using Tailwind CSS which is available via tw- prefix, e.g. tw-relative. Gitea's helper CSS classes use gt- prefix (gt-ellipsis), while Gitea's own private framework-level CSS classes use g- prefix (g-modal-confirm).
13. Avoid inline scripts & styles as much as possible, it's recommended to put JS code into JS files and use CSS classes. If inline scripts & styles are unavoidable, explain the reason why it can't be avoided.

In history, Gitea heavily uses Fomantic UI which is not an accessibility-friendly framework. Gitea uses some patches to make Fomantic UI more accessible (see aria.md and related JS files), but there are still many problems which need a lot of work and time to fix.

Mixing different frameworks together is discouraged, it makes the code difficult to be maintained. A JavaScript module should follow one major framework and follow the framework's best practice.

Recommended implementations:

• Vue + Vanilla JS
• Fomantic-UI (jQuery)
• htmx (partial page reloads for otherwise static components)
• Vanilla JS

Discouraged implementations:

• Vue + Fomantic-UI (jQuery)
• jQuery + Vanilla JS
• htmx + any other framework which requires heavy JS code, or unnecessary features like htmx scripting (hx-on)

To make UI consistent, Vue components can use Fomantic-UI CSS classes. We use htmx for simple interactions. You can see an example for simple interactions where htmx should be used in this PR. Do not use htmx if you require more advanced reactivity, use another framework (Vue/Vanilla JS). Although mixing different frameworks is discouraged, it should also work if the mixing is necessary and the code is well-designed and maintainable.

Gitea is in the process of migrating to type-safe Typescript. Here are some specific guidelines regarding Typescript in the codebase:

Prefer to use type aliases because they can represent any type and are generally more flexible to use than interfaces.

We use verbatimModuleSyntax so type and non-type imports from the same file must be split into two import type statements. This enables the typescript compiler to completely eliminate the type import statements during compilation.

Both annotations should be avoided, but if you have to use them, use @ts-expect-error because it will not leave ineffective statements after the issue is fixed.

Only mark a function as async if and only if there are await calls or Promise returns inside the function.

It's not recommended to use async event listeners, which may lead to problems. The reason is that the code after await is executed outside the event dispatch. Reference: https://github.com/github/eslint-plugin-github/blob/main/docs/rules/async-preventdefault.md

If an event listener must be async, the e.preventDefault() should be before any await, it's recommended to put it at the beginning of the function.

If we want to call an async function in a non-async context, it's recommended to use const _promise = asyncFoo() to tell readers that this is done by purpose, we want to call the async function and ignore the Promise. Some lint rules and IDEs also have warnings if the returned Promise is not handled.

To fetch data, use the wrapper functions GET, POST etc. from modules/fetch.js. They accept a data option for the content, will automatically set CSRF token and return a Promise for a Response.

The usage of dataset is forbidden, its camel-casing behaviour makes it hard to grep for attributes. However, there are still some special cases, so the current guideline is:

• For legacy code:

  • $.data() should be refactored to $.attr().
  • $.data() can be used to bind some non-string data to elements in rare cases, but it is highly discouraged.

• For new code:

  • node.dataset should not be used, use node.getAttribute instead.
  • never bind any user data to a DOM node, use a suitable design pattern to describe the relation between node and data.

• Vue components are recommended to use v-if and v-show to show/hide elements.
• Go template code should use .tw-hidden and showElem()/hideElem()/toggleElem(), see more details in .tw-hidden's comment.

It's recommended to use:

<div class="gt-name1 gt-name2 {{if .IsFoo}}gt-foo{{end}}" {{if .IsFoo}}data-foo{{end}}></div>

instead of:

<div class="gt-name1 gt-name2{{if .IsFoo}} gt-foo{{end}}"{{if .IsFoo}} data-foo{{end}}></div>

to make the code more readable.

A lot of legacy code already existed before this document's written. It's recommended to refactor legacy code to follow the guidelines.

Gitea is using Vue3 now. We decided not to introduce JSX to keep the HTML and the JavaScript code separated.

Gitea uses some self-made UI elements and customizes others to integrate them better into the general UI approach. When running Gitea in development mode (RUN_MODE=dev), a page with some standardized UI examples is available under http(s)://your-gitea-url:port/devtest.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4