Inconsistent payload type definition in `pushEvent` / `pushEventTo`

[rhcarvalho]

While working on #4220, I noticed that HookInterface.pushEvent (and ViewHook.pushEvent) defines the payload type to be any, while HookInterface.pushEventTo (and ViewHook.pushEventTo) says object.

• phoenix_live_view/assets/js/phoenix_live_view/view_hook.ts

  Line 90 in 10e1ad5

  pushEvent(event: string, payload: any, onReply: OnReply): void;

• phoenix_live_view/assets/js/phoenix_live_view/view_hook.ts

  Lines 114 to 119 in 10e1ad5

  	pushEventTo(
  	selectorOrTarget: PhxTarget,
  	event: string,
  	payload: object,
  	onReply: OnReply,
  	): void;

The Elixir/server-side code expects an Elixir map (i.e. JS object):

• phoenix_live_view/lib/phoenix_live_view.ex

  Lines 324 to 325 in 10e1ad5

  	@callback handle_event(event :: binary, unsigned_params(), socket :: Socket.t()) ::
  	{:noreply, Socket.t()} | {:reply, map, Socket.t()}

• phoenix_live_view/lib/phoenix_live_view.ex

  Line 231 in 10e1ad5

  @type unsigned_params :: map

---

I think I tripped up on this once trying to push a non-object payload, though on the surface it feels like any JSON-serializable value could do.

Tightening up the typespec from any to object could trigger downstream warnings/errors, so flagging the inconsistence here to decide whether we any->object, object->any or do nothing.

[SteffenDE]

I guess we should change object to any, since you can do this.pushEvent("foo", "bar") and it works just fine.

[SteffenDE]

(So technically, you can push anything that the channel's serializer can encode, which usually is JSON)

[rhcarvalho]

I guess we should change object to any, since you can do this.pushEvent("foo", "bar") and it works just fine.

Should we consider changing unsigned_params from map to term on the Elixir side? It's been that way since at least 2018 (commit 7e0d7fe).

A quick local test and not only could I push integer, string, and array payloads, but also even the event name could be a non-string!

Hooks.Test = {
  mounted() {
    this.pushEvent("test_non_object_payload", 1)
    this.pushEvent("test_non_object_payload", "one")
    this.pushEvent("test_non_object_payload", [1, 2])
    this.pushEvent("test_non_object_payload", ["one", "two"])
    this.pushEvent(7, 13)
    this.pushEvent([1, 2], {})
    this.pushEvent({complex: "name"}, {})
  }
}

  def handle_event(name, payload, socket) do
    dbg(%{name: name, payload: payload})
    {:noreply, socket}
  end

Even though those work, I think some of them should not be part of the supported contract? Outside of pushEvent in hooks, form submissions, phx-click, etc, tend to send name as string and the payload constructed as a map/object.

[SteffenDE]

I'm fine with changing the handle_event signature to term(). Maybe we mention that the payload is usually a map, deserialized from JSON.

The event name itself is already typed as string on the client. If someone relies on that right now, it definitely works by accident, so it wouldn't be a problem to change it in the future, if we ever have to.