Understanding widget operations

[lufte]

I have postponed upgrading my Iced dependency for long enough, so this week I started porting my app from Iced 0.4 to 0.9. One of the biggest changes are the new pure widgets and their operations.

I wonder why the new widget operations need to be Commands. With impure widgets I could update their state immediately by calling the appropriate function on their State struct, but now the operations return a Command that I need to return from my update method. If the function that was doing the update was way up in the stack, now I need to pass around this new Command all the way back to update so it can be returned. I guess (because I haven't actually tested it yet) this also prevents me from updating a widget's state and then querying the new value within the same invocation of update, as it won't be really updated until the Command is executed.

Anyway, just wondering about the motivations for some of these decisions. No malice intended, still loving Iced <3

[hecrj]

Widget operations are side effects of the update logic. Similar to a Command that runs some Future.

iced is inspired by Elm, a pure functional language. As a result, iced follows the Elm Architecture, which exposes side effects as a first-class concept.

Even if we changed the architecture, operations work on the widget tree and we will always be forced to either returning them or providing a new argument to record them.

And even if we wanted to offer a way to execute operations in update logic itself, this is not possible because operations operate on the result of view and view borrows self but update mutates self. Because of the borrow rules, update can never access the result of view directly.

[lufte]

I guess the difference with the previous versions (<0.5) was that back then, the state of widgets was part of the state of my application, so updating that state would not be considered a side effect; if I'm following this correctly.

And even if we wanted to offer a way to execute operations in update logic itself, this is not possible because operations operate on the result of view

This part is also new, right? Back then I could alter my widget's state inside update but I didn't have access to anything else. Now, according to what you say and the following quote from the RFC, I could query extra stuff that wasn't possible before:

Many useful operations should be possible with this design and could be built-in in the library, like querying the current size of a particular widget or controlling a Scrollable programmatically.

Thank you for your response!