-
Notifications
You must be signed in to change notification settings - Fork 120
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
I've decided on the name "xilem" rather than "idiopath," and this also matches the blog post (now linked from the README, though that is a bit stale).
- Loading branch information
0 parents
commit 26432ce
Showing
26 changed files
with
2,778 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
[package] | ||
name = "xilem" | ||
version = "0.1.0" | ||
license = "Apache-2.0" | ||
authors = ["Raph Levien <[email protected]>"] | ||
edition = "2021" | ||
|
||
[dependencies] | ||
"druid-shell" = { path = "../druid-shell" } | ||
bitflags = "1.3.2" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,80 @@ | ||
# An experimental Rust architecture for reactive UI | ||
|
||
Note: this README is a bit out of date. To understand more of what's going on, please read the blog post, [Xilem: an architecture for UI in Rust]. | ||
|
||
This repo contains an experimental architecture, implemented with a toy UI. At a very high level, it combines ideas from Flutter, SwiftUI, and Elm. Like all of these, it uses lightweight view objects, diffing them to provide minimal updates to a retained UI. Like SwiftUI, it is strongly typed. | ||
|
||
## Overall program flow | ||
|
||
Like Elm, the app logic contains *centralized state.* On each cycle (meaning, roughly, on each high-level UI interaction such as a button click), the framework calls a closure, giving it mutable access to the app state, and the return value is a *view tree.* This view tree is fairly short-lived; it is used to render the UI, possibly dispatch some events, and be used as a reference for *diffing* by the next cycle, at which point it is dropped. | ||
|
||
We'll use the standard counter example. Here the state is a single integer, and the view tree is a column containing two buttons. | ||
|
||
```rust | ||
fn app_logic(data: &mut u32) -> impl View<u32, (), Element = impl Widget> { | ||
Column::new(( | ||
Button::new(format!("count: {}", data), |data| *data += 1), | ||
Button::new("reset", |data| *data = 0), | ||
)) | ||
} | ||
``` | ||
|
||
These are all just vanilla data structures. The next step is diffing or reconciling against a previous version, now a standard technique. The result is an *element tree.* Each node type in the view tree has a corresponding element as an associated type. The `build` method on a view node creates the element, and the `rebuild` method diffs against the previous version (for example, if the string changes) and updates the element. There's also an associated state tree, not actually needed in this simple example, but would be used for memoization. | ||
|
||
The closures are the interesting part. When they're run, they take a mutable reference to the app data. | ||
|
||
## Components | ||
|
||
A major goal is to support React-like components, where modules that build UI for some fragment of the overall app state are composed together. | ||
|
||
```rust | ||
struct AppData { | ||
count: u32, | ||
} | ||
|
||
fn count_button(count: u32) -> impl View<u32, (), Element = impl Widget> { | ||
Button::new(format!("count: {}", count), |data| *data += 1) | ||
} | ||
|
||
fn app_logic(data: &mut AppData) -> impl View<AppData, (), Element = impl Widget> { | ||
Adapt::new(|data: &mut AppData, thunk| thunk.call(&mut data.count), | ||
count_button(data.count)) | ||
} | ||
``` | ||
|
||
This adapt node is very similar to a lens (quite familiar to existing Druid users), and is also very similar to the [Html.map] node in Elm. Note that in this case the data presented to the child component to render, and the mutable app state available in callbacks is the same, but that is not necessarily the case. | ||
|
||
## Memoization | ||
|
||
In the simplest case, the app builds the entire view tree, which is diffed against the previous tree, only to find that most of it hasn't changed. | ||
|
||
When a subtree is a pure function of some data, as is the case for the button above, it makes sense to *memoize.* The data is compared to the previous version, and only when it's changed is the view tree build. The signature of the memoize node is nearly identical to [Html.lazy] in Elm: | ||
|
||
```rust | ||
fn app_logic(data: &mut AppData) -> impl View<AppData, (), Element = impl Widget> { | ||
Memoize::new(data.count, |count| { | ||
Button::new(format!("count: {}", count), |data: &mut AppData| { | ||
data.count += 1 | ||
}) | ||
}), | ||
} | ||
``` | ||
|
||
The current code uses a `PartialEq` bound, but in practice I think it might be much more useful to use pointer equality on `Rc` and `Arc`. | ||
|
||
The combination of memoization with pointer equality and an adapt node that calls [Rc::make_mut] on the parent type is actually a powerful form of change tracking, similar in scope to Adapton, self-adjusting computation, or the types of binding objects used in SwiftUI. If a piece of data is rendered in two different places, it automatically propagates the change to both of those, without having to do any explicit management of the dependency graph. | ||
|
||
I anticipate it will also be possible to do dirty tracking manually - the app logic can set a dirty flag when a subtree needs re-rendering. | ||
|
||
## Optional type erasure | ||
|
||
By default, view nodes are strongly typed. The type of a container includes the types of its children (through the `ViewTuple` trait), so for a large tree the type can become quite large. In addition, such types don't make for easy dynamic reconfiguration of the UI. SwiftUI has exactly this issue, and provides [AnyView] as the solution. Ours is more or less identical. | ||
|
||
The type erasure of View nodes is not an easy trick, as the trait has two associated types and the `rebuild` method takes the previous view as a `&Self` typed parameter. Nonetheless, it is possible. (As far as I know, Olivier Faure was the first to demonstrate this technique, in [Panoramix], but I'm happy to be further enlightened) | ||
|
||
[Html.lazy]: https://guide.elm-lang.org/optimization/lazy.html | ||
[Html map]: https://package.elm-lang.org/packages/elm/html/latest/Html#map | ||
[Rc::make_mut]: https://doc.rust-lang.org/std/rc/struct.Rc.html#method.make_mut | ||
[AnyView]: https://developer.apple.com/documentation/swiftui/anyview | ||
[Panoramix]: https://github.com/PoignardAzur/panoramix | ||
[Xilem: an architecture for UI in Rust]: https://raphlinus.github.io/rust/gui/2022/05/07/ui-architecture.html |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,46 @@ | ||
// Copyright 2022 The Druid Authors. | ||
// | ||
// Licensed under the Apache License, Version 2.0 (the "License"); | ||
// you may not use this file except in compliance with the License. | ||
// You may obtain a copy of the License at | ||
// | ||
// http://www.apache.org/licenses/LICENSE-2.0 | ||
// | ||
// Unless required by applicable law or agreed to in writing, software | ||
// distributed under the License is distributed on an "AS IS" BASIS, | ||
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
// See the License for the specific language governing permissions and | ||
// limitations under the License. | ||
|
||
use xilem::{button, v_stack, Adapt, App, AppLauncher, LayoutObserver, Memoize, View}; | ||
|
||
#[derive(Default)] | ||
struct AppData { | ||
count: u32, | ||
} | ||
|
||
fn count_button(count: u32) -> impl View<u32> { | ||
button(format!("count: {}", count), |data| *data += 1) | ||
} | ||
|
||
fn app_logic(data: &mut AppData) -> impl View<AppData> { | ||
v_stack(( | ||
format!("count: {}", data.count), | ||
button("reset", |data: &mut AppData| data.count = 0), | ||
Memoize::new(data.count, |count| { | ||
button(format!("count: {}", count), |data: &mut AppData| { | ||
data.count += 1 | ||
}) | ||
}), | ||
Adapt::new( | ||
|data: &mut AppData, thunk| thunk.call(&mut data.count), | ||
count_button(data.count), | ||
), | ||
LayoutObserver::new(|size| format!("size: {:?}", size)), | ||
)) | ||
} | ||
|
||
pub fn main() { | ||
let app = App::new(AppData::default(), app_logic); | ||
AppLauncher::new(app).run(); | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,152 @@ | ||
// Copyright 2022 The Druid Authors. | ||
// | ||
// Licensed under the Apache License, Version 2.0 (the "License"); | ||
// you may not use this file except in compliance with the License. | ||
// You may obtain a copy of the License at | ||
// | ||
// http://www.apache.org/licenses/LICENSE-2.0 | ||
// | ||
// Unless required by applicable law or agreed to in writing, software | ||
// distributed under the License is distributed on an "AS IS" BASIS, | ||
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
// See the License for the specific language governing permissions and | ||
// limitations under the License. | ||
|
||
use druid_shell::kurbo::Size; | ||
use druid_shell::piet::{Color, Piet, RenderContext}; | ||
use druid_shell::{kurbo::Point, WindowHandle}; | ||
|
||
use crate::widget::{CxState, EventCx, LayoutCx, PaintCx, Pod, UpdateCx, WidgetState}; | ||
use crate::{ | ||
event::Event, | ||
id::Id, | ||
view::{Cx, View}, | ||
widget::{RawEvent, Widget}, | ||
}; | ||
|
||
pub struct App<T, V: View<T>, F: FnMut(&mut T) -> V> { | ||
data: T, | ||
app_logic: F, | ||
view: Option<V>, | ||
id: Option<Id>, | ||
state: Option<V::State>, | ||
events: Vec<Event>, | ||
window_handle: WindowHandle, | ||
root_state: WidgetState, | ||
root_pod: Option<Pod>, | ||
size: Size, | ||
cx: Cx, | ||
} | ||
|
||
const BG_COLOR: Color = Color::rgb8(0x27, 0x28, 0x22); | ||
|
||
impl<T, V: View<T>, F: FnMut(&mut T) -> V> App<T, V, F> | ||
where | ||
V::Element: Widget + 'static, | ||
{ | ||
pub fn new(data: T, app_logic: F) -> Self { | ||
let cx = Cx::new(); | ||
App { | ||
data, | ||
app_logic, | ||
view: None, | ||
id: None, | ||
state: None, | ||
root_pod: None, | ||
events: Vec::new(), | ||
window_handle: Default::default(), | ||
root_state: Default::default(), | ||
size: Default::default(), | ||
cx, | ||
} | ||
} | ||
|
||
pub fn ensure_app(&mut self) { | ||
if self.view.is_none() { | ||
let view = (self.app_logic)(&mut self.data); | ||
let (id, state, element) = view.build(&mut self.cx); | ||
let root_pod = Pod::new(element); | ||
self.view = Some(view); | ||
self.id = Some(id); | ||
self.state = Some(state); | ||
self.root_pod = Some(root_pod); | ||
} | ||
} | ||
|
||
pub fn connect(&mut self, window_handle: WindowHandle) { | ||
self.window_handle = window_handle.clone(); | ||
// This will be needed for wiring up async but is a stub for now. | ||
//self.cx.set_handle(window_handle.get_idle_handle()); | ||
} | ||
|
||
pub fn size(&mut self, size: Size) { | ||
self.size = size; | ||
} | ||
|
||
pub fn paint(&mut self, piet: &mut Piet) { | ||
let rect = self.size.to_rect(); | ||
piet.fill(rect, &BG_COLOR); | ||
|
||
self.ensure_app(); | ||
loop { | ||
let root_pod = self.root_pod.as_mut().unwrap(); | ||
let mut cx_state = CxState::new(&self.window_handle, &mut self.events); | ||
let mut update_cx = UpdateCx::new(&mut cx_state, &mut self.root_state); | ||
root_pod.update(&mut update_cx); | ||
let mut layout_cx = LayoutCx::new(&mut cx_state, &mut self.root_state); | ||
root_pod.prelayout(&mut layout_cx); | ||
let proposed_size = self.size; | ||
root_pod.layout(&mut layout_cx, proposed_size); | ||
if cx_state.has_events() { | ||
// We might want some debugging here if the number of iterations | ||
// becomes extreme. | ||
self.run_app_logic(); | ||
} else { | ||
let mut paint_cx = PaintCx::new(&mut cx_state, piet); | ||
root_pod.paint(&mut paint_cx); | ||
break; | ||
} | ||
} | ||
} | ||
|
||
pub fn mouse_down(&mut self, point: Point) { | ||
self.event(RawEvent::MouseDown(point)); | ||
} | ||
|
||
fn event(&mut self, event: RawEvent) { | ||
self.ensure_app(); | ||
let root_pod = self.root_pod.as_mut().unwrap(); | ||
let mut cx_state = CxState::new(&self.window_handle, &mut self.events); | ||
let mut event_cx = EventCx::new(&mut cx_state, &mut self.root_state); | ||
root_pod.event(&mut event_cx, &event); | ||
self.run_app_logic(); | ||
} | ||
|
||
pub fn run_app_logic(&mut self) { | ||
for event in self.events.drain(..) { | ||
let id_path = &event.id_path[1..]; | ||
self.view.as_ref().unwrap().event( | ||
id_path, | ||
self.state.as_mut().unwrap(), | ||
event.body, | ||
&mut self.data, | ||
); | ||
} | ||
// Re-rendering should be more lazy. | ||
let view = (self.app_logic)(&mut self.data); | ||
if let Some(element) = self.root_pod.as_mut().unwrap().downcast_mut() { | ||
let changed = view.rebuild( | ||
&mut self.cx, | ||
self.view.as_ref().unwrap(), | ||
self.id.as_mut().unwrap(), | ||
self.state.as_mut().unwrap(), | ||
element, | ||
); | ||
if changed { | ||
self.root_pod.as_mut().unwrap().request_update(); | ||
} | ||
assert!(self.cx.is_empty(), "id path imbalance on rebuild"); | ||
} | ||
self.view = Some(view); | ||
} | ||
} |
Oops, something went wrong.