Should Actions be generalized to pass their output to a callback instead of putting it into a signal

[Kritzefitz]

Currently an Action broadly combines these three functionalities:

• Dispatch executions of an asynchronous action
• Track if the action is currently executing via .pending and .input
• Store the output of the action in a signal once the action completes

This similarly applies to MultiActions, which allow to track multiple in-flight actions, but each submission of the action still tracks if the action is still running and stores the output in a signal once available.

It seems to me, like storing the output of the action in a signal is unnecessarily inflexible for at least some use cases.

Let's take the todo_app_sqlite as an example. We have a list of Todos that are loaded on the client side and we allow the user to add to this list and to delete items from the list. These changes to the list are synchronized to the server using Actions (broadly speaking, actually ServerAction and ServerMultiAction are used, but the difference shouldn't matter for my example). Once an action to change the list has completed, the displayed list needs to be updated to reflect the changes. In the current example, this is achieved by subscribing the Resource todos to delete_todo.version() and add_todo.version(), which triggers a reload of the todos whenever they are changed. This achieves the intended result of updating the displayed list on changes, but it seems unnecessarily inefficient to reload the entire list of todos when we've actually done a very simple change to it. We rely on the server to calculate the new list of todos for us, causing a lot of transfer overhead, when we could relatively simply calculate the effect of our change to the list relatively easily on the client side. If we modify get_todos to return a RwResult<Vec<Todos>> we gain the ability to modify the list of todos on the client side after retrieving it, but we'd still need to arrange for completions of add_todo and delete_todo to be synchronized into the todos.

This sounds easy enough on the surface, but it would actually be a little more complicated to implement, because we only gain access to the result of an action through a signal and AFAIK there's no way to sync changes in one signal to another signal, without a trip through an effect, which is generally frowned upon. So in this case, the fact that an action wraps its output in a signal seems to be less of a feature, but more of a hindrance.

I think it would be easier to model interactions like this, if we had variants of Actions that don't automatically store their output in a signal, but instead just receive a callback to call on each completion. For lack of a better name, I'll call them EventAction for now and they would probably look somewhat like this:

pub struct EventAction<I, O, S = SyncStorage> { /* ... */ }

impl<I: Send + Sync + 'static, O: Send + Sync + 'static> Action<I, O> {
  pub fn new<F, Fut, P>(action_fn: F, process_result: P) -> Self 
  where
    F: Fn(&I) -> Fut + Send + Sync + 'static,
    Fut: Future<Output = O> + Send + 'static,
    P: Fn(&I, O) + Send + Sync + 'static,
{ /* ... */ }

The rest of the interface would be very similar to Action, the only difference being that there's no .value and instead every time the action completes, the passed process_result is called with a reference to the input to the completed submission and the output.

For plain Actions this might not be entirely useful, since we could just merge the logic from process_result into action_fn's returned future, but the benefit becomes more clear for EventServerAction where the server function would take the place of action_fn but we would still provide process_result upon construction, so the server function would run on the server side, while process_result would run on the client side.

This concept can similarly be extended to EventMultiActions, with the semantics of process_result being the same and the only difference being that entries in .submissions don't provide access to .value.

I'm not entirely confident, but I think that the current behavior Action and MultiAction could be implemented in terms of EventAction and EventMultiAction, since all you'd have to do is to create a signal for the result and provide a process_result that updates the signal appropriately.

I'd be willing to take a stab at implementing this, but before I do, I wanted to ask if this seems like a useful idea. Does this solve an actual problem or is there an easier solution to the problem in the todo_app_sqlite example I described? Does anyone have a suggestion for a good name to differentiate these callback-based actions from traditional actions? Are the benefits worth the complexity of doubling the variants of actions we have? Since where we have now Action, MultiAction, ServerAction, and MultiServerAction this would add EventAction, EventMultiAction, EventServerAction and EventMultiServerAction.

[gbj]

It is completely fine to create a different primitive that does this; I have no interest in making breaking changes to Action itself.

I'm also not really interested in multiplying the number of different combinations that exist in the library itself in the way described, as I ultimately end up maintaining everything that gets added over time.

I'm pretty sure this can be implemented in userland or as a library, although I may be wrong.

Whether the "invalidate with an action and reload with a resource" pattern is good or not is kind of an orthogonal question.

[Kritzefitz]

It is completely fine to create a different primitive that does this; I have no interest in making breaking changes to Action itself.

I agree. Breaking the existing API of Actions isn't my aim here. Ideally the new primitive would be powerful enough to serve as a basis for the implementation of the current Actions (and friends), but that should be done in a backwards-compatible way, if at all.

I'm also not really interested in multiplying the number of different combinations that exist in the library itself in the way described, as I ultimately end up maintaining everything that gets added over time.

I'm pretty sure this can be implemented in userland or as a library, although I may be wrong.

I also think this can be implemented as a library. Though I think having this in leptos could bring some benefits:

• As mentioned above, I think this new primitive could used as a basis to implement other Actions, which would prevent code duplication, but necessitates having this new primitive in leptos.
• ActionForm currently only works on ServerAction, but AIUI only requires it to provide an action url and have a way to dispatch a form submission, whereas it doesn't care about how the result of the action is actually presented after submission. This means ActionForms could be extended to work on both existing ServerActions and on the server variant of this new primitive as well, whereas an implementation outside of leptos would have to bring its own flavor of an action form.

However, I'd be completely fine with implementing this in another library.

Whether the "invalidate with an action and reload with a resource" pattern is good or not is kind of an orthogonal question.

Correct. I mostly mentioned this as an example of a problem that I think could be more easily solved if we had this primitive. But it is not directly related to the concept itself.

Overall I think my next step should be to implement this concept in a library. Then we can evaluate if it makes sense to keep the library separately or if and how it makes sense to integrate it into leptos.