Drab tutorial error

I believe I’ve fixed this issue, now module-specific assigns are being added to assigns. Expect the fix in 0.10.0, coming very soon (maybe today?)

There are two types of standard payload sent from the client to to handler - information about the sender, so the object on which the event was launched, and internal data, specific to the used module - like, in this example, drab_index which is used by Drab.Live.

Considering this, exec_elixir should send the module-specific data. This is what I would expect. So I will update it, as Add module-specific payload when calling exec_elixir() · Issue #174 · grych/drab · GitHub

Thanks for the update, the explanation makes sense. I am no Drab expert let alone the creator so the following input is just to provide feedback from a user.

I read in the Drab.exec_elixir() documentation it requires the elixir function named in the first argument to be

1. in the commander,
2. to be a handler.

This lead me to expect it to act like the other handlers and have the default payload passed in and not behave differently based on the handler’s caller being drab-click() vs exec_elixir().

Leaving Drab.exec_elixir() unchanged and adding Drab.exec_handler() may continue the issue where a handler will act differently depending on how it is called, even though all three methods are designed to call handlers.

I am not sure whether changing Drab.exec_handler() might break someone’s code so can’t speak to the risk/value of changing it. I like that exec_handler is named more explicitly in that the called function is required to be a handler. So I guess I lean toward option 2, and maybe decide to keep unchanged and possibly deprecate exec_elixir() at some point unless it has some other purpose than calling handlers.
My 2c.

Thanks again for the great package, really enjoying it.

I know where the issue is. The problem is rather fundamental and I must think how to solve it.

Normally, when you run the Drab Handler via JS event (drab-click etc), the default payload is passed to the server, which contains also __drab.index in pages which have Drab.Live enabled.

But you run Drab.exec_elixir(). In this case, only the parameters you give to the method are passed. If you add drab_index to the exec_elixir, all should work:

Drab.exec_elixir('position_changed', {\"lat\":pos.coords.latitude, \"lon\": pos.coords.longitude, \"drab_index\": __drab.index});

I can see 2 possible fixes for this case:

1. add default payload to Drab.exec_elixir()
2. create new method Drab.exec_handler() which will have default payload, and leave exec_elixir clean.

I believe it is a bug, it should not act like this. Let me try to reproduce it on my environment.

I believe it can be isolated to the exec_js call setup in page_loaded() so this is what I tried:

  def page_loaded(socket) do
    ...
    socket |> IO.inspect(label: "**SOCKET: ")
    {status, return_value} = exec_js(socket, "navigator.geolocation.watchPosition(function(pos){debugger;Drab.exec_elixir('position_changed', {\"lat\":pos.coords.latitude, \"lon\": pos.coords.longitude, \"drab\": __drab.index});}, function(err){}, {});", timeout: 1000)
  end

And in the first line of

defhandler position_changed(socket, payload) do
    payload["drab"] |> IO.inspect(label: "__drab.index")
    socket |> IO.inspect(label: "**SOCKET-0: ")
    ...
end

What I see is the socket is correct inside page_loaded, but not in the position_changed() handler. It seems good inside the browser as you can see from the passed in value that is printed payload[“drab”]

OUTPUT: inside page_loaded()

**SOCKET: : %Phoenix.Socket{
  assigns: %{
    __action: :index,
   ...
    __drab_index: "gi2dqnbygazdenbv",
  ...

OUTPUT: Inside position_chaged() handler

__drab.index: "gi2dqnbygazdenbv"
**SOCKET-0: : %Phoenix.Socket{
  assigns: %{
    __action: :index,
    ...
    __drab_index: nil,
    ...

Phoenix.Socket.assigns.__drab_index looks good initially inside page_loaded() and stays good until the first call to position_chaged(), when it is passed in the socket value as nil.

It seems that __drab.index is correct in the browser context, but not sure if there is a better way to test what you are asking. Let me know.

Can you check the value of __drab.index on the client side?

Ran into this error message when upgrading from 7.2 to 9.3 and a quick search brought me here. Error is

(ArgumentError) template `main` not found.

Please make sure this partial exists and has been compiled
by Drab (has *.drab extension).

If you want to poke assign to the partial which belong to
the other view, you need to specify the view name in `poke/4`.

    (drab) lib/drab/live.ex:1014: Drab.Live.raise_partial_not_found/1
    (drab) lib/drab/live.ex:890: Drab.Live.assigns_for_partial/5
    (drab) lib/drab/live.ex:600: Drab.Live.do_poke/5

At first I was confused because I was calling poke/2 not poke/4 but after a bit of investigation I see that poke/2 ends up at do_poke/5 using a template id held in socket.assigns. It looks like something is clearing __drab_index: as it goes from __drab_index: “gi2dqnbygazdenbv” to __drab_index: nil in socket.assigns.

I suspect it is an exec_js call I use in the page_loaded callback:

{status, return_value} = exec_js(socket, "navigator.geolocation.watchPosition(function(pos){Drab.exec_elixir('position_changed', {\"lat\":pos.coords.latitude, \"lon\": pos.coords.longitude});}, function(err){}, {});", timeout: 1000)

The solution for me was to use peek/3 & poke/3 to be explicit about the template I want in the poke/peek calls instead of counting on the value to stay clean in assigns.

If I can isolate/verify that the cause of __drab_index getting reset to nil isn’t something in my code I will report it as a bug on github, but thought I would leave a quick note here in case I don’t get to that soon and others run into a similar issue.

Good idea

Actually, in this case Drab should show the better error message. I’ve added the nil case to assigns function, and now:

iex(20)> poke socket, something: 42
** (ArgumentError) template `main` not found.

Please make sure this partial exists and has been compiled
by Drab (has *.drab extension).

If you want to poke assign to the partial which belong to
the other view, you need to specify the view name in `poke/4`.

    (drab) lib/drab/live.ex:1005: Drab.Live.raise_partial_not_found/1
    (drab) lib/drab/live.ex:878: Drab.Live.assigns_for_partial/5
    (drab) lib/drab/live.ex:588: Drab.Live.do_poke/5