Modules¶

Components declared in a .slint file can be used as elements in other .slint files, by means of exporting and importing them.

By default, every type declared in a .slint file is private. The export keyword changes this.

component ButtonHelper inherits Rectangle {
    // ...
}

component Button inherits Rectangle {
    // ...
    ButtonHelper {
        // ...
    }
}

export { Button }

In the above example, Button is accessible from other .slint files, but ButtonHelper isn’t.

It’s also possible to change the name just for the purpose of exporting, without affecting its internal use:

component Button inherits Rectangle {
    // ...
}

export { Button as ColorButton }

In the above example, Button isn’t accessible from the outside, but is available under the name ColorButton instead.

For convenience, a third way of exporting a component is to declare it exported right away:

export component Button inherits Rectangle {
    // ...
}

Similarly, components exported from other files may be imported:

import { Button } from "./button.slint";

export component App inherits Rectangle {
    // ...
    Button {
        // ...
    }
}

In the event that two files export a type under the same name, then you have the option of assigning a different name at import time:

import { Button } from "./button.slint";
import { Button as CoolButton } from "../other_theme/button.slint";

export component App inherits Rectangle {
    // ...
    CoolButton {} // from other_theme/button.slint
    Button {} // from button.slint
}

Elements, globals and structs can be exported and imported.

It’s also possible to export globals (see Global Singletons) imported from other files:

import { Logic as MathLogic } from "math.slint";
export { MathLogic } // known as "MathLogic" when using native APIs to access globals

Module Syntax¶

The following syntax is supported for importing types:

import { export1 } from "module.slint";
import { export1, export2 } from "module.slint";
import { export1 as alias1 } from "module.slint";
import { export1, export2 as alias2, /* ... */ } from "module.slint";

The following syntax is supported for exporting types:

// Export declarations
export component MyButton inherits Rectangle { /* ... */ }

// Export lists
component MySwitch inherits Rectangle { /* ... */ }
export { MySwitch }
export { MySwitch as Alias1, MyButton as Alias2 }

// Re-export types from other module
export { MyCheckBox, MyButton as OtherButton } from "other_module.slint";

// Re-export all types from other module (only possible once per file)
export * from "other_module.slint";

Component Libraries¶

Splitting your code base into separate module files promotes re-use and improves encapsulation by allow you to hide helper components. This works well within a project’s own directory structure. To share libraries of components between projects without hardcoding their relative paths, use the component library syntax:

import { MySwitch } from "@mylibrary";

In the above example, the MySwitch component will be imported from a component library called “mylibrary”. The path to this library must be defined separately at compilation time. Use one of the following methods to help the Slint compiler resolve “mylibrary” to the correct path on disk:

When using Rust and build.rs, call with_library_paths to provide a mapping from library name to path.
When invoking the slint-viewer from the command line, pass -Lmylibrary=/path/to/my/library for each component library.
When using the VS Code extension, configure the Slint extension’s library path using the Slint: Library Paths setting. Example below:
```
"slint.libraryPaths": {
    "mylibrary": "/path/to/my/library"
},
```
With other editors, you can configure them to pass the -L argument to the slint-lsp just like for the slint-viewer.