Lifecycle diagram

[Folyd]

Thank this awesome project that has made cross-platform UI development an easier way in the Rust world.

I know iced is just at a very early stage, we don't have enough good docs yet. We can get started through a set of examples. However, after insight a lot of examples, I still can't get a clear concept and relationship of every single component, such as the Application's lifecycle, when and how frequency the view() and update() get called, how State, Element and Message, etc interact. So, just hoping we have a lifecycle or relationship diagram for brevity clarification to the developer. Maybe the Android Activity lifecycle, Vue lifecycle diagrams are such a good instance.

[hecrj]

The library follows The Elm Architecture quite closely. Therefore, any existing material about it should be relatively useful.

Although I keep all the public API documented to some extent, I agree we need to work on additional resources (like a website with a guide or tutorial). However, it's hardly one of my main priorities right now (see the ROADMAP).

That said, I believe writing documentation like tutorials or blog posts is a very good way to start CONTRIBUTING. I'd really appreciate any help.

when and how frequency the view() and update() get called, how State, Element and Message, etc interact

Why do you want to know more about this? As a user, you should not need to understand/rely on the frequency of view and update. This is an implementation detail of the runtime, and it will change once we start performing optimizations.

The contract will only specify that view should create a widget tree that produces messages on user interaction. Then, these messages will eventually be processed by update.

[Folyd]

Thankful to @hecrj .

Why do you want to know more about this? As a user, you should not need to understand/rely on the frequency of view and update. This is an implementation detail of the runtime, and it will change once we start performing optimizations.

To some extent, as a user, if you aim to build an efficient and robust application, you'd better know the underhood. I think that is why the Android and Vue team give such a lifecycle diagram.

In another one, if a user wants to give a contribution, a lifecycle or architecture diagram is an extra helpful resource to get started. :)

[hecrj]

To some extent, as a user, if you aim to build an efficient and robust application, you'd better know the underhood. I think that is why the Android and Vue team give such a lifecycle diagram.

I believe we should try to keep the contract as simple as possible. If the users of a library need to know internal details to use it properly, then some abstraction is most likely failing.

There may be advanced use cases where knowing all the details is necessary, but I am not sure we should be focusing on those at this point.

In another one, if a user wants to give a contribution, a lifecycle or architecture diagram is an extra helpful resource to get started.

As I said, the architecture Iced follows is not particularly new by any means. I think there is a good amount of content already out there if you want to understand the basic idea of it. For instance, the main README links to the Elm guide section describing it.

When it comes to the details... Yes, there are some differences. However, these differences are very likely to change. In fact, we want them to be easy to change. Writing documentation means investing effort in pinning these details down and can make us less likely to try new things (sunk cost fallacy!).

We absolutely do not want this at the current stage of the project. We need as much space for exploration as possible.

For now, I feel comfortable addressing any questions raised in issues or our Zulip server.

[krooq]

I personally think this would be a great thing to have. Every framework/engine that I have used has been made so much clearer to use from the lifecycle diagram. Unity, JavaFX, Android to name a few. I think Iced has grown to a point where not all it's features are immediately obvious, e.g. subs and command are definitely more advanced and it would be great to see these things on a big picture diagram. The elm diagram is.... well its pretty basic to say the least.

For others reading this post looking for an overview of the lifecycle in some more detail check out the application.rs for example in iced_winit, it helped me to understand how things all link in. Like when events are processed, when widget functions are called and when the main application functions get called.

I'll have a look at making a quick diagram this weekend while I learn it myself and I'll post back here with what I come up with (hopefully).

[krooq]

I have a work in progress flowchart here https://drive.google.com/open?id=1qzBXyDE8KQ-FQPr9L2wb2UG63bA77zdrnwg5H5La2ow feel free to add comments/edit responsibly.

It's pretty much just application.rs for iced_winit and its too low level for a front page flowchart but if you are learning I hope it helps. It's got the widget flows in the left and the async stuff on the right. I aim to make this much much simpler so that it is the same for web. The completed version should be platform agnostic as the framework is.

I also want to stress that this is not by any means complete, correct or part of any public API. As Hector said, the framework is subject to change and this is no reflection of the API, it's a learning tool only so you can look at the source and understand it at a higher level.

[krooq]

Ok here is a simpler version.