Utilizing an asynchronous observer pattern to delegate work

Learn
1

In Iced, we have our primary Application struct. Conceptually, this is where I like to delegate my UI event handlers. That is, all events that directly affect or are affected by the UI. What about non-blocking work?
Suppose I have an expensive function I want to run called think. I would like think to not block the application while it’s running. The flow would look something like this.

  • User clicks think button
  • Application broadcasts a think clicked event of some kind
  • Application recognizes the event, handles it by spinning up a separate thread T or something
  • T eventually finishes thinking function, and broadcasts the result back to the Application
  • Application picks up the finished event with the data, and updates the Application state accordingly

I have spent the past few days working with Iced’s Subscriptions to try to work with this, but haven’t made much progress. Does Iced support this sort of behavior easily?
Thanks.

2

Isn’t Command::perform what you are looking for? Plenty of examples use Command, like the pokedex.

3

I’ll check and follow up

4

This may be a much better alternative to my headspace. I’ll work on this approach and come back again with my findings to resolve the thread.

5

To conclude this one for now, utilizing Command seems like a workable solution. You can use perform to run an asynchronous operation and pass the result into an associated event, which fits my use case. Refer to @hecrj’s post for direct links to more info.
As an aside, I do wonder about the extensibility of this struct, however. For example, is it possible to cancel a command after it has been run? That may be better suited for a different topic though.