4

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:

  • Username/password authentication in a conventional flow
  • OpenAuth-style authentication with a third-party involved and a redirect
  • Token or cookie authentication behind the scenes
  • Server-side validation of form inputs
  • Submission of a command for a remote shell

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.

Community
  • 1
  • 1
tacos_tacos_tacos
  • 10,277
  • 11
  • 73
  • 126
  • A `PotAction` is just a convenient sub type of `AsyncAction` that uses a `Pot`, that explains why you have the "same" methods. – jpmelanson May 16 '16 at 13:55

1 Answers1

4

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.

ochrons
  • 691
  • 5
  • 10
  • Would it be safe to say that you might use `PotStream` for handling a web sockets response? – tacos_tacos_tacos May 17 '16 at 16:13
  • 2
    Not really as the concepts are quite different. `PotStream` represents a (potentially infinite) stream of data, of which the client wants to see a given range. Imagine something like a chat conversation with a long history. With `PotStream` you can model the chat history, adding new messages to both ends of the streams to reflect how the user is scrolling the chat history. You may use web sockets to update the stream automatically, but you cannot model a web socket as a `PotStream`. – ochrons May 19 '16 at 13:22