|
An operation may take longer than a single tick of the event loop, and may have it's own rules regarding state transitions. To be clear, I'm not saying "don't do any communication by sharing state", just that there are use cases where it's possible to make it much simpler to reason about. As an example, you might control the state of "making a HTTP request to perform a search", within the frontend of a single page app that has a map, search filters, and results. One strategy is to use a buffered channel (1 element), and, when the search filters are updated, drain then re-send the request to the channel. The logic processing these requests would then just need to sit there, iterating on / receiving from the channel. It could also support cancellation, if that was desired. (I'd imagine the results would be propagated via some other mechanism, e.g. to a store implementation) |