Using signals and exposing signals to actions?

[sundbp]

I'm finding myself wishing for an escape hatch to be able to use signals, and mixing in signals to actions. Example:
I have a text input field where I'd like to submit and trigger an action on enter and deal with the input. The natural way is to use a signal, data-bind, and only deal with the "hit-enter" case. I don't want to ping every keystroke over and so forth.

It looks like actions use a @post, so all signals will already be part of what the action scaffolding recieves, and it could be exposed in a similar way to $key$, $value etc.

Just checking in on what the design philosophy is with regards to having some kind of client-side only state and using signals.

[rschmukler]

Hey! Thanks for the interest and apologies on the delay - I realized I wasn't watching my own repo 🫤

Generally the philosophy is that almost everything should be server side, but I think your use case makes a lot of sense.

I think there are a few potential routes we could go:

1. We could extend the action macro to try and be smart of certain things that can be resolved purely client side, smartly handling things like:

{:data-on:keydown (action (when (= $key "Enter") ...)}

2. We could extend action to perhaps take a map as an optional first argument and have some client side logic in it:

{:data-on:keydown (action {:when (= $key "Enter")} ...)}

3. We could introduce some string helpers

(let [on-enter (action ...)]
  {:data-on:keydown (h/on-key "Enter" on-enter)})

I think my gut leans towards 2 but I'm open to thoughts.

[sundbp]

I agree with the "most state is server side", but I think the case for a generic signals escape hatch is pretty strong. Typically you don't want a bunch of signals, but I think very often a couple of them that are purely client side and allows data-bind etc to work without forced server round trips have a lot of value. Which to me would suggest not "hardcoding" anything like $key, but having a more permissive way to interact with signals in actions as they are getting shipped over by @post() to the actions endpoint. An ergonomic way to mix generic signals is my hope.

[rschmukler]

Do you have any ideas around what you wished the API looked like? What do you wish you could write? Could help to give us something less abstract to ground the design in.

[rschmukler]

Expanding with another thought: action just returns the fetch / post string, but as such there's nothing preventing you from using that string elsewhere.

[sundbp]

Example: data-bind the value of text input to a signal, then have a data-on:keydown expression that filters for the Enter key at the browser side, but allows a backend side action, e.g. (str "evt.key === 'EntER' && " (action ... use the signalbound to the value .. ).
No pingpong to server for every key stroke, and get the value we need at the point we need it.
How you dig out the signal value in the action cold be something like (get-signal "theSignal"), which looks it up in the signals that got supplied in the post.