why not impl component?

[adsick]

Hi, I'm just starting reading through dioxus documentation and I'm thinking that some things could be designed in a different, more rust idiomatic way.
what I've understood so far is that you have props (that are structs with derive Props) and you have components which are functions that accept cx: Scope<Props>. Props are the data used by component and each component uses only one Props

idk, but for me it looks a lot like

//maybe some macro here
pub struct PersonComponent{
    name: String,
    age: u8,
}

//maybe some macro here too
impl Component for PersonComponent{
    fn render(&self, context?) -> something {
    ...
    }
    fn update(evt: Event, maybe context?) {
    ...
    }
    //maybe some other stuff
}

possible considerations are

trait Component{...};
trait OwnedComponent: Component{...};
trait BorrowedComponent: Component{...};

don't judge hard, I am sleepy and don't know what I'm talking about.

[rMazeiks]

Thanks for your thoughts!

some things could be designed in a different, more rust idiomatic way.

You are right in that there are lots of possible design choices that can be made. But there doesn't seem to be much consensus in the Rust community about what the idiomatic approach to UIs is. There are a lot of different crates that take different approaches. Raph Levien has a cool blog post that, among other things, summarizes some of the existing architectures.

Your Component trait with the render and update methods is a valid approach! In fact, it looks a bit similar to Iced. Personally, I have tried both Dioxus and Iced, and, though Iced does indeed seem a bit more idiomatic, it's also a bit of a pain to write. My main concerns are:

• To handle an event, you have to create a struct of possible messages, dispatch a message, and handle every possible message – very verbose. In Dioxus, you can just handle it with a closure.
• You have to manage all state manually – a component owns it's children's state. More "correct", I guess, but more annoying to write and edit. In Dioxus, the framework magically keeps track of state most of the time (though if you have a collection of children, you have to provide identifiers for them)

But Dioxus has taken a different path – it is based on React functional components. And this architecture I believe makes great developer experience (which React is famous for). It's really easy to write, read and maintain once you get used to it. Of course, it has drawbacks as well. Levien writes:

[Dioxus and similar frameworks] rely on interior mutability and other patterns that I think adapt poorly to Rust [(I think he is referring to hooks)]

I agree that interior mutability is "not great" as it bypasses Rust's amazing compile-time borrow checker, leading to possible panics at runtime. Though in practice, this hasn't been an issue for me.

And I have mixed feelings about hooks. They are very much unlike anything else in the Rust ecosystem. And they have "weird" rules that I wish could be enforced at compile time. Even in React they were not without controversy. But they are really easy to use, and compose nicely.

//maybe some macro here
//maybe some other stuff

It sounds like you are underestimating the complexity that goes into a UI framework a little bit :) State management is hard. Layout is hard. Event handling is hard. Exposing an ergonomic API is hard. Though you're welcome to try making your own framework if you don't believe me (been there. done that. failed 3 times lol).

---

Anyway. I encourage you to try out writing the same interface in various frameworks and see which one you like best. I can suggest Dioxus, Egui, and Iced – they each have their own strengths!

Though Dioxus is my favorite at the moment. It's really pleasant to work with, and practical. And it renders to HTML, which means you get all the good stuff of the web (complex layouts, any kind of text (e.g. RTL), CSS, SVG, responsiveness, transitions, accessibility, cross-platform rendering, etc.). I hate HTML but it has evolved to contain basically anything you would need for a "normal" UI.

(disclaimer: i am not a maintainer; these are my personal opinions)

[adsick]

thanks for the reply.

It's really easy to write, read and maintain once you get used to it.

mine "impl Component" approach is even more readable as it is common to see in Rust.

It sounds like you are underestimating the complexity that goes into a UI framework a little bit :) State management is hard...

maybe, but I feel like Dioxus could manage state as good as it does it (but with this design) it is more about what programmer sees and writes, not about what's happening underneath.

you're welcome to try making your own framework if you don't believe me

indeed I do beleive