Do you just put the entire application logic into one impl block?

[kartonrad]

Hello!
I've been trying iced, and thouh i think the architecture is cool, it often leaves me scratching my head at what i think are the simplest things

I have a Widget/Component in mind that i would use a lot, it's supposed to be an extension of the ImageViewer, that asynchronously loads normal and RAW images, then displays them in a pannable way.
Since it's a viewer (and doesn't modify anything), it doesn't affect the rest of the applications state,
but it might have plenty of it's own, especially when i add analyzing features, like metadata viewers/graphs to it.

However, even after somehow understanding how Components work, from the example...
(that for some reason was implemented in a renderer-agnostic fashion, so i had to figure out that i can just use iced::Renderer for the generics, and plenty of other nonsense - it took such a long time to get familiar with the internals )

I noticed that Components don't offer async support, so i can't really use the commands etc.
(which makes them absolutely useless: my application freezes every time an image loads or it makes a request
so i think Components aren't really designed for this purpose and i might be on the wrong track)

so:
do i just... skip using components?
and do everything in the main application?

like do i just add all messages for all of these components etc into one big, maybe nested enum?
(like ImageViewerMessage(id=1, event=msg) )

because all my efforts to abstract have done so far, is cause me suffering.
is there a good practice for encapsulating smaller chunks of the application?
or is that just not something this lib does??

[kartonrad]

Ok i get it

Widgets are always synchronous

[kartonrad]

pain

[DaraJKong]

Iced is based on the Elm architecture. Like Raph Levien mentioned in his article: "the Elm architecture does not support cleanly factored components." And the Elm documentation says: "Actively trying to make components is a recipe for disaster in Elm."

I encourage you to read on the Elm documentation if you want to know more about the architecture: https://guide.elm-lang.org/architecture/

[kartonrad]

Ok so i dug through and i think i discovered the way to decouple logic in ELM arcitecture.

Key ist the .map method on Command and Element Types...
https://docs.iced.rs/iced_native/struct.Element.html#method.map
The documentation is actually super helpful and explains decoupling!
It's just that by the point you know to search for Element.map, you must've already figured out the approach on your own...
If just the iced book had a short chapter referring to it, i think the doc situation would be in much better shape already
So i might contribute to it, if i find the time, but i at this point have a really poor understanding, so idk.

Then i implemented following Traits (hopefully they weren't hidden in iced already, it's hard to know):

Intending to streamline the process of making smaller submodules.
The update method still has to manually delegate updates, and new must be called and the command must be passed on...
I think this has both drawbacks and advantages

It does force you to take all the control in the higher classes
But it's not a bad compromise.

i might try to make a method update_children:: that is implemented for all Applications whose messages that implement MessageBridge (but that seems kinda difficult to achieve, so maybe i'll leave it alone for now)
But i don't know how far i can and should take this.
For now this is a really solid start and i think, even if verbose, i could design the whole application around this.

[tarkah]

I'd highly recommend not using a trait as above. You want to keep your plumbing code very flexible, as thing will be changing in your application all the time.

What happens when you need to pass some state down view for one screen but not the others?

Enums & module::view / module::update, etc are more than sufficient with .map.

[kartonrad]

What happens when you need to pass some state down view for one screen but not the others?

I guess in that case i would give up the convenience of my update/view/new_into methods, and not use the trait

To be clear, i'd think that storing all "children" in a
Vec<Box< dyn Model > > would defeat the purpose of elm
(Also i don't know if thats even possible, since rust needs to now the specific Message type for delegation of updates)

These traits are just for reducing "map" calls in my code