Pauan
commented
5 years ago I really appreciate the interest in dominator! I'm impressed you managed to figure things out despite the lack of docs and tutorial (which I am working on).
If I understand properly, rust-signals is conceptually like Erlang message passing. Or Actor frameworks like Rust actix, but more lightweight.
I don't have any experience with Erlang/actor style message passing, but I don't think they're related.
Instead, Signals are based on "functional reactive programming", which is used in Haskell and Elm.
Signals can be used for things like distributed systems, but they accomplish that in a very different way from Erlang.
It's best not to think of Signals as "sending messages", instead it's best to think of them as more like a mutable variable: they have a current value, and that value can then change to something else.
Unlike mutable variables, you can be efficiently notified when a Signal changes, allowing for changes to automatically propagate throughout your app.
So you set up your app as a network of these Signals, and then data flows through the Signals automatically (and very efficiently).
Rather than using messages, instead you just use raw data (such as integers, strings, etc.), just like how you would with mutable variables.
And unlike Erlang message queues, Signals do not guarantee that every change is observed, and it is possible for changes to occur out of order.
That might sound scary, but it's actually completely fine! You just have to treat Signals as being like mutable variables, rather than treating them like event listeners or message queues.
You can read more about that in this thread: https://github.com/Pauan/rust-signals/issues/1#issuecomment-432915099
specifically optimized for your primary use case rust-dominator
It is true that I designed rust-signals alongside rust-dominator.
It is also true that rust-dominator was the primary motivation for rust-signals.
However, rust-signals was carefully designed to be general purpose, and it can be used for many things.
I read the reusable component issue, where you mentioned queues. If I understand properly, queues are a way to make the whole thing look like an Elm (or seed) approach where all state updates are done in an update function, so the view contains less state update logic.
That is correct. Though I had imagined that it could be used for a variety of purposes: an entire app driven by queues, a single component driven by queues, etc.
Are you still planning to add this to rust-dominator?
I haven't put any thought or effort into it. I'm not against it, I just haven't had a personal need for it. Using Mutable has worked out really well on all of the projects I've done.
Things have improved a lot since the "Reusable components" issue. So most of the pain points and difficulties have already been fixed.
So I'm personally in favor of extremely light-weight components (basically just a struct) which use Mutable internally.
Here's an example:
-
I have a top-level
Statestruct which has arendermethod. -
It contains a
Gamestruct which has its ownrendermethod. Storing a struct inside of a struct is how state composition happens. -
Similarly,
Gamecontains other structs such asTiles, etc. The hierarchy can be as deep as you want. -
The
State::rendermethod calls theGame::rendermethod. This is how view composition happens. -
The
Gamestruct can expose various public methods, which can then be called by variousStatemethods. This is how behavior composition happens. -
The
Statemethods can be called by events (and those methods will then update internal state, call variousGamemethods, etc.).
And... that's pretty much it. A component is just a Rust struct. It contains internal state in fields. It contains methods for updating that state. You store a struct inside of another struct to compose them. You call the render method to compose another component's view inside of your component. You call methods from events to update things.
Everything is just completely ordinary Rust techniques, there's no need for anything fancy like queues. This keeps everything light-weight, fast, and easy to understand.
The only difficulty is when it comes to events: sometimes a component needs to pass information upwards in the hierarchy (e.g. a child component notifying a parent component that something has happened).
In that case you have a few options:
-
Pass the parent component into the child component's
rendermethod, and have the child component call the parent's methods. -
Pass in a closure to the child component's
rendermethod, this closure will get called when the event happens. -
The child component can contain a queue, and the parent can then pull from that queue.
The third option is the most interesting, so let's see how that would look like:
#[derive(Clone, Copy)]
pub enum Event {
LeftClick,
RightClick,
}
pub struct Child {
events: Queue<Event>,
}
impl Child {
pub fn new() -> Arc<Self> {
Arc::new(Self {
events: Queue::new(),
})
}
pub fn events(&self) -> impl Stream<Item = Event> {
self.events.stream()
}
pub fn render(state: Arc<Self>) -> Dom {
html!("div", {
.event(clone!(state => move |_: ClickEvent| {
state.events.push(Event::LeftClick);
}))
.event(clone!(state => move |_: ContextMenuEvent| {
state.events.push(Event::RightClick);
}))
})
}
}
pub struct Parent {
child: Arc<Child>,
}
impl Parent {
pub fn new() -> Arc<Self> {
Arc::new(Self {
child: Child::new(),
})
}
pub fn render(state: Arc<Self>) -> Dom {
html!("div", {
.future(state.child.events().for_each(|event| {
match event {
Event::LeftClick => {
...
},
Event::RightClick => {
...
},
}
async {}
}))
.children(&mut [
Child::render(state.child.clone()),
])
})
}
}Basically, it uses the same structure described above (structs + normal methods), except the Child now has an events() method, which returns a Stream of Event. The Parent can then use .future + for_each to listen for those events.
However, I think even this is too heavy-weight, and I would personally just do this:
#[derive(Clone, Copy)]
pub enum Event {
LeftClick,
RightClick,
}
pub struct Child {
}
impl Child {
pub fn new() -> Arc<Self> {
Arc::new(Self {
})
}
pub fn render<F>(state: Arc<Self>, on_event: F) -> Dom where F: FnMut(Event) {
let events = EventDispatcher::new(on_event);
html!("div", {
.event(clone!(events => move |_: ClickEvent| {
events.send(Event::LeftClick);
}))
.event(clone!(events => move |_: ContextMenuEvent| {
events.send(Event::RightClick);
}))
})
}
}
pub struct Parent {
child: Arc<Child>,
}
impl Parent {
pub fn new() -> Arc<Self> {
Arc::new(Self {
child: Child::new(),
})
}
pub fn render(state: Arc<Self>) -> Dom {
html!("div", {
.children(&mut [
Child::render(state.child.clone(), move |event| {
match event {
Event::LeftClick => {
...
},
Event::RightClick => {
...
},
}
}),
])
})
}
}In this case the Parent just passes in a closure to the Child::render method. Internally it uses an EventDispatcher to allow it to call the closure from multiple different events.
EventDispatcher would be defined like this:
#[derive(Debug, Clone)]
pub struct EventDispatcher<F> {
listener: Arc<Mutex<F>>,
}
impl<F> EventDispatcher<F> {
pub fn new(listener: F) -> Self {
Self {
listener: Arc::new(Mutex::new(listener)),
}
}
}
impl<A, F> EventDispatcher<F> where F: FnMut(A) {
pub fn send(&self, event: A) {
let mut listener = self.listener.lock().unwrap();
listener(event);
}
}This is pretty much the fastest and most light-weight way to handle this problem. It's also very natural, from a Rust perspective.
Are there disadvantages for such a Queue approach like elimination of the rust-signal performance gain over Elm-like approaches ?
There could be! It depends on how you use the queues. If you use queues to update Mutables, then there will only be a small constant performance loss, so it should still be very fast.
But if you use queues to drive the rendering, then yeah you basically get the Elm/yew/seed model, which is inherently slow (since it either has to do DOM diffing, value diffing, or both).
Could push-to-queue and direct-signal-to-model (as we have it now) both be used together ? I imagine for things things like animations, which have their own internal state, one does not want to propagate things up to the the message queue.
Yeah, that was the original idea (discussed in the "Reusable components" issue): using a queue to manage updates, but internally it would be mutating a bunch of Mutables (or MutableAnimations). So integrating the two is definitely possible.
But I've now come to the conclusion that queues are unnecessary and just add bloat. I'm open to changing my mind, but I haven't needed queues so far.
One more specific question about dom.StyleSheetBuilder. Where is that getting used ?
It's used by the stylesheet! macro.
You use it like this:
stylesheet!("div", {
.style("background-color", "green")
});That's equivalent to this CSS file:
div {
background-color: green;
}Basically, it allows you to create "raw" stylesheets, where you can specify the CSS selector.
It's rarely used (since class! is much better). The primary reason to use it is to change the styles of html and body, like this:
stylesheet!("html, body", {
.style("width", "100%")
.style("height", "100%")
.style("margin", "0px")
.style("padding", "0px")
});Or you can use it to apply styles to every element in the page:
stylesheet!("*", {
.style("font-family", "sans-serif")
.style("font-size", "13px")
});In the examples, style changes are directly applied to dom HTML elements (if I understood properly).
That depends. If you use .style or .style_signal, then indeed it applies CSS styles directly to the DOM element.
However, you can also use .class and .class_signal, as shown in the counter example.
The way that it works is that when you use class! it creates a <style> element, and creates a new unique class name, and then injects the CSS styles into the <style>.
In other words, if you do this:
static ref FOO_CLASS: String = class! {
.style("background-color", "green")
};Then it basically generates this:
<style>
.__class_0__ {
background-color: green;
}
</style>(Technically it doesn't actually serialize the CSS styles, instead it just uses insertRule. But the end result is the same.)
And then when you use .class(&*FOO_CLASS), it just adds __class_0__ to the className of the DOM element.
This is much more efficient than individually setting styles on the DOM element, but it has the same effect.
This is a really awesome technique which almost no DOM frameworks use (I don't know why, it has no downsides).
What is the roadmap for rust-dominator ?
It's feature-complete, just needs some docs and tutorial.
I recently made a short overview post here: https://github.com/rustwasm/team/issues/243
Not really a roadmap, but it does give some high-level information.
It is based on stdweb, but since wasm-bindgen became usable, it seems to me that all new stuff in wasm space is based on wasm-bindgen.
Yeah, that's mostly because the Rust Wasm WG has always pushed heavily for wasm-bindgen.
I think it's a shame that stdweb has gotten so little credit, since it's always been far ahead of wasm-bindgen (and still is).
But eventually wasm-bindgen will catch up, and I think that's a good thing in the long run.
Is there any technical reason preventing rust-dominator from being based on wasm-bindgen ?
Yeah, a bunch. wasm-bindgen is very different in features and API, so it'll take some work to port it over (and probably some changes to wasm-bindgen).
But I am very interested in porting dominator to work with wasm-bindgen, it's currently my number 1 priority.
rsaccon
nothingIsSomething
While doing research for adding spring animations to a seed-based app, I discovered this project. I am totally blown away by the signal-based concept and all the advanced and highly performant stuff packed into this framework. Especially the animations example! Here some questions which piled up, while digging into
rust-dominatorandrust-signals:If I understand properly,
rust-signalsis conceptually like Erlang message passing. Or Actor frameworks like Rust actix, but more lightweight and specifically optimized for your primary use caserust-dominator. Please correct me if I am wrong.I read the reusable component issue, where you mentioned queues. If I understand properly, queues are a way to make the whole thing look like an Elm (or seed) approach where all state updates are done in an
updatefunction, so theviewcontains less state update logic. @Pauan Are you still planning to add this torust-dominator? Are there disadvantages for such a Queue approach like elimination of therust-signalperformance gain over Elm-like approaches ? Could push-to-queue and direct-signal-to-model (as we have it now) both be used together ? I imagine for things things like animations, which have their own internal state, one does not want to propagate things up to the the message queue.One more specific question about dom.StyleSheetBuilder. Where is that getting used ? In the examples, style changes are directly applied to dom HTML elements (if I understood properly). But the code from the StyleSheetBuilder suggests to me that this is for collecting styles from the element definitions in the view and building a stylesheet out of it, for injection into the HTML page.
What is the roadmap for
rust-dominator? It is based onstdweb, but sincewasm-bindgenbecame usable, it seems to me that all new stuff in wasm space is based onwasm-bindgen. Is there any technical reason preventingrust-dominatorfrom being based onwasm-bindgen?