Utilizing an asynchronous observer pattern to delegate work

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?

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

I’ll check and follow up

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.

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.