In the scala
and scalajs
library Diode
, I have used but not entirely understood the PotAction
class and only recently discovered the AsyncAction
class, both of which seem to be favored in situations involving, well, asynchronous requests. While I understand that, I don't entirely understand the design decisions and the naming choices, which seem to suggest a more narrow use case.
Specifically, both AsyncAction
and PotAction
require an initialModel
and a next
, as though both are modeling an asynchronous request for some kind of refreshable, updateable content rather than a command in the sense of CQRS. I have a somewhat-related question open regarding synchronous actions on form inputs by the way.
I have a few specific use cases in mind. I'd like to know a sketch (not asking for implementation, just the concept) of how you use something like PotAction
in conjunction with any of:
All of these seem to be a bit different in nature to what I've seen using PotAction
but I really want to use it because it has already been helpful when I am, say, rendering something based on the current state of the Pot
.
Historically speaking, PotAction
came first and then at a later time AsyncAction
was generalized out of it (to support PotMap
and PotVector
), which may explain their relationship a bit. Both provide abstraction and state handling for processing async actions that retrieve remote data. So they were created for a very specific (and common) use case.
I wouldn't, however, use them for authentication as that is typically something you do even before your application is loaded, or any data requested from the server.
Form validation is usually a synchronous thing, you don't do it in the background while user is doing something else, so again Async/PotAction
are not a very good match nor provide much added value.
Finally for the remote command use case PotAction
might be a good fit, assuming you want to show the results of the command to the user when they are ready. Perhaps PotStream
would be even better, depending on whether the command is producing a steady stream of data or just a single message.
In most cases you should use the various Pot
structures for what they were meant for, that is, fetching and updating remote data, and maybe apply some of the ideas or internal models (such as the retry mechanism) to other request types.
All the Pot
stuff was separated from Diode core into its own module to emphasize that they are just convenient helpers for working with Diode. Developers should feel free to create their own helpers (and contribute back to Diode!) for new use cases.