最佳实践

在以下章节中，我们分享多年来积累的经验教训。这将帮助你避免一些陷阱和棘手情况，并提升 UI 代码的可维护性。

无障碍

设计自定义组件时，应尽早考虑声明无障碍属性。至少包含 role，可能还包括 label，以及各种 actions。

如果你在 Windows 上开发，那么 Accessibility Insights 这款 Windows 工具可以帮助你发现并修复无障碍问题。

如果你在 macOS 上开发，Accessibility Inspector 提供了类似功能。注意，它要求应用以 bundle 形式构建。

component CustomButton {
    // ...
    in property <string> text;

    accessible-role: button;
    accessible-label: self.text;
    accessible-action-default => { /* simulate click */ }
}

slint

分离代码、UI 与资源

许多项目起步时规模很小，只有几个文件。但不知不觉间，团队壮大、文件增多，就越来越难看清全局。我们建议从以下基本目录结构开始：

my-project
├── src
│   ├── main.cpp / main.rs / main.js / main.py
│        <this is where your main business logic lives>
├── ui
    ├── app-window.slint <the entry point for your Slint UI>
    ├── <additional .slint files here>
    ├── images
        ├── logo.svg
        ├── highlight-marker.svg
        ├── <all your images go here>

plaintext

翻译

在向 UI 添加用户可见的字符串时，应尽早用 @tr("...") 包裹，将其标记为可翻译。
避免使用 + 拼接字符串，优先使用 {} 替换。这样译者就能重新排列参数顺序，得到最自然的译文。

export component Example {
    property <string> name;

    Text {
        text: "Ink Level Controls"; // Oooops, forgot to mark as translatable
    }
    Text {
        text: @tr("Hello, ") + name; // Oooops, this is difficult to translate
    }
}

slint

export component Example {
    property <string> name;

    Text {
        text: @tr("Ink Level Controls");
    }
    Text {
        text: @tr("Hello, {}", name); // Good, now the translator can re-order
    }
}

slint