1# Rust coding guidelines
2
3* Prioritize code correctness and clarity. Speed and efficiency are secondary priorities unless otherwise specified.
4* Do not write organizational or comments that summarize the code. Comments should only be written in order to explain "why" the code is written in some way in the case there is a reason that is tricky / non-obvious.
5* Prefer implementing functionality in existing files unless it is a new logical component. Avoid creating many small files.
6* Avoid using functions that panic like `unwrap()`, instead use mechanisms like `?` to propagate errors.
7* Be careful with operations like indexing which may panic if the indexes are out of bounds.
8* Never silently discard errors with `let _ =` on fallible operations. Always handle errors appropriately:
9 - Propagate errors with `?` when the calling function should handle them
10 - Use `.log_err()` or similar when you need to ignore errors but want visibility
11 - Use explicit error handling with `match` or `if let Err(...)` when you need custom logic
12 - Example: avoid `let _ = client.request(...).await?;` - use `client.request(...).await?;` instead
13* When implementing async operations that may fail, ensure errors propagate to the UI layer so users get meaningful feedback.
14* Never create files with `mod.rs` paths - prefer `src/some_module.rs` instead of `src/some_module/mod.rs`.
15* When creating new crates, prefer specifying the library root path in `Cargo.toml` using `[lib] path = "...rs"` instead of the default `lib.rs`, to maintain consistent and descriptive naming (e.g., `gpui.rs` or `main.rs`).
16* Avoid creative additions unless explicitly requested
17* Use full words for variable names (no abbreviations like "q" for "queue")
18* Use variable shadowing to scope clones in async contexts for clarity, minimizing the lifetime of borrowed references.
19 Example:
20 ```rust
21 executor.spawn({
22 let task_ran = task_ran.clone();
23 async move {
24 *task_ran.borrow_mut() = true;
25 }
26 });
27 ```
28
29# GPUI
30
31GPUI is a UI framework which also provides primitives for state and concurrency management.
32
33## Context
34
35Context types allow interaction with global state, windows, entities, and system services. They are typically passed to functions as the argument named `cx`. When a function takes callbacks they come after the `cx` parameter.
36
37* `App` is the root context type, providing access to global state and read and update of entities.
38* `Context<T>` is provided when updating an `Entity<T>`. This context dereferences into `App`, so functions which take `&App` can also take `&Context<T>`.
39* `AsyncApp` and `AsyncWindowContext` are provided by `cx.spawn` and `cx.spawn_in`. These can be held across await points.
40
41## `Window`
42
43`Window` provides access to the state of an application window. It is passed to functions as an argument named `window` and comes before `cx` when present. It is used for managing focus, dispatching actions, directly drawing, getting user input state, etc.
44
45## Entities
46
47An `Entity<T>` is a handle to state of type `T`. With `thing: Entity<T>`:
48
49* `thing.entity_id()` returns `EntityId`
50* `thing.downgrade()` returns `WeakEntity<T>`
51* `thing.read(cx: &App)` returns `&T`.
52* `thing.read_with(cx, |thing: &T, cx: &App| ...)` returns the closure's return value.
53* `thing.update(cx, |thing: &mut T, cx: &mut Context<T>| ...)` allows the closure to mutate the state, and provides a `Context<T>` for interacting with the entity. It returns the closure's return value.
54* `thing.update_in(cx, |thing: &mut T, window: &mut Window, cx: &mut Context<T>| ...)` takes a `AsyncWindowContext` or `VisualTestContext`. It's the same as `update` while also providing the `Window`.
55
56Within the closures, the inner `cx` provided to the closure must be used instead of the outer `cx` to avoid issues with multiple borrows.
57
58Trying to update an entity while it's already being updated must be avoided as this will cause a panic.
59
60When `read_with`, `update`, or `update_in` are used with an async context, the closure's return value is wrapped in an `anyhow::Result`.
61
62`WeakEntity<T>` is a weak handle. It has `read_with`, `update`, and `update_in` methods that work the same, but always return an `anyhow::Result` so that they can fail if the entity no longer exists. This can be useful to avoid memory leaks - if entities have mutually recursive handles to each other they will never be dropped.
63
64## Concurrency
65
66All use of entities and UI rendering occurs on a single foreground thread.
67
68`cx.spawn(async move |cx| ...)` runs an async closure on the foreground thread. Within the closure, `cx` is an async context like `AsyncApp` or `AsyncWindowContext`.
69
70When the outer cx is a `Context<T>`, the use of `spawn` instead looks like `cx.spawn(async move |handle, cx| ...)`, where `handle: WeakEntity<T>`.
71
72To do work on other threads, `cx.background_spawn(async move { ... })` is used. Often this background task is awaited on by a foreground task which uses the results to update state.
73
74Both `cx.spawn` and `cx.background_spawn` return a `Task<R>`, which is a future that can be awaited upon. If this task is dropped, then its work is cancelled. To prevent this one of the following must be done:
75
76* Awaiting the task in some other async context.
77* Detaching the task via `task.detach()` or `task.detach_and_log_err(cx)`, allowing it to run indefinitely.
78* Storing the task in a field, if the work should be halted when the struct is dropped.
79
80A task which doesn't do anything but provide a value can be created with `Task::ready(value)`.
81
82## Elements
83
84The `Render` trait is used to render some state into an element tree that is laid out using flexbox layout. An `Entity<T>` where `T` implements `Render` is sometimes called a "view".
85
86Example:
87
88```
89struct TextWithBorder(SharedString);
90
91impl Render for TextWithBorder {
92 fn render(&mut self, _window: &mut Window, _cx: &mut Context<Self>) -> impl IntoElement {
93 div().border_1().child(self.0.clone())
94 }
95}
96```
97
98Since `impl IntoElement for SharedString` exists, it can be used as an argument to `child`. `SharedString` is used to avoid copying strings, and is either an `&'static str` or `Arc<str>`.
99
100UI components that are constructed just to be turned into elements can instead implement the `RenderOnce` trait, which is similar to `Render`, but its `render` method takes ownership of `self`. Types that implement this trait can use `#[derive(IntoElement)]` to use them directly as children.
101
102The style methods on elements are similar to those used by Tailwind CSS.
103
104If some attributes or children of an element tree are conditional, `.when(condition, |this| ...)` can be used to run the closure only when `condition` is true. Similarly, `.when_some(option, |this, value| ...)` runs the closure when the `Option` has a value.
105
106## Input events
107
108Input event handlers can be registered on an element via methods like `.on_click(|event, window, cx: &mut App| ...)`.
109
110Often event handlers will want to update the entity that's in the current `Context<T>`. The `cx.listener` method provides this - its use looks like `.on_click(cx.listener(|this: &mut T, event, window, cx: &mut Context<T>| ...)`.
111
112## Actions
113
114Actions are dispatched via user keyboard interaction or in code via `window.dispatch_action(SomeAction.boxed_clone(), cx)` or `focus_handle.dispatch_action(&SomeAction, window, cx)`.
115
116Actions with no data defined with the `actions!(some_namespace, [SomeAction, AnotherAction])` macro call. Otherwise the `Action` derive macro is used. Doc comments on actions are displayed to the user.
117
118Action handlers can be registered on an element via the event handler `.on_action(|action, window, cx| ...)`. Like other event handlers, this is often used with `cx.listener`.
119
120## Notify
121
122When a view's state has changed in a way that may affect its rendering, it should call `cx.notify()`. This will cause the view to be rerendered. It will also cause any observe callbacks registered for the entity with `cx.observe` to be called.
123
124## Entity events
125
126While updating an entity (`cx: Context<T>`), it can emit an event using `cx.emit(event)`. Entities register which events they can emit by declaring `impl EventEmittor<EventType> for EntityType {}`.
127
128Other entities can then register a callback to handle these events by doing `cx.subscribe(other_entity, |this, other_entity, event, cx| ...)`. This will return a `Subscription` which deregisters the callback when dropped. Typically `cx.subscribe` happens when creating a new entity and the subscriptions are stored in a `_subscriptions: Vec<Subscription>` field.
129
130## Recent API changes
131
132GPUI has had some changes to its APIs. Always write code using the new APIs:
133
134* `spawn` methods now take async closures (`AsyncFn`), and so should be called like `cx.spawn(async move |cx| ...)`.
135* Use `Entity<T>`. This replaces `Model<T>` and `View<T>` which no longer exist and should NEVER be used.
136* Use `App` references. This replaces `AppContext` which no longer exists and should NEVER be used.
137* Use `Context<T>` references. This replaces `ModelContext<T>` which no longer exists and should NEVER be used.
138* `Window` is now passed around explicitly. The new interface adds a `Window` reference parameter to some methods, and adds some new "*_in" methods for plumbing `Window`. The old types `WindowContext` and `ViewContext<T>` should NEVER be used.
139
140
141## General guidelines
142
143- Use `./script/clippy` instead of `cargo clippy`