Raise if JS.dispatch detail is not a map (#4062)

Today I discovered a bug in a LiveView application where a string was
passed as the detail option to JS.dispatch instead of a map (as
documented).

It turns out it accidentally worked with the default `esbuild` config.

The bug remained unnoticed for a long time because by default `app.js`
is not compiled in JavaScript strict mode. When the config was changed
to output ESM modules (which are always in strict mode), the error
surfaced.

The exact line of code in Phoenix LiveView client code where the error is raised:
https://github.com/phoenixframework/phoenix_live_view/blob/98088bc7458d1821d9d9bb38caa3145a0b93ee9c/assets/js/phoenix_live_view/js.js#L77
Note that line has been there for many years.

This is the explanation of the error in MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Cant_assign_to_property

LiveView code is correct and follows the documented API. Since we
already do validations and raise on other invalid inputs, we can prevent
future mistakes by ensuring that the detail option is a map.

Author: rhcarvalho

lib/phoenix_live_view/js.ex

@@ -366,9 +366,14 @@ defmodule Phoenix.LiveView.JS do
               })
           """
 
-        {_, {:ok, detail}} ->
+        {_, {:ok, detail}} when is_map(detail) ->
           Keyword.put(args, :detail, detail)
 
+        {_, {:ok, detail}} ->
+          raise ArgumentError, """
+          the detail option to JS.dispatch must be a map, got: #{inspect(detail)}
+          """
+
         {_, :error} ->
           args
       end

test/phoenix_live_view/js_test.exs

@@ -483,6 +483,12 @@ defmodule Phoenix.LiveView.JSTest do
         JS.dispatch("foo", detail: %{done: true}, blocking: true)
       end
     end
+
+    test "raises when detail is not a map" do
+      assert_raise ArgumentError, ~r/the detail option to JS.dispatch must be a map/, fn ->
+        JS.dispatch("foo", detail: "not-a-map")
+      end
+    end
   end
 
   describe "toggle" do