Drab tutorial error

Questions / Help
, ,
1

Hi everyone,

I’m going through the tutorial for drab and got to the case example. After copying the code from the example to my own files, I ran iex -S mix phx.server and visited localhost. When I clicked the uppercase button, I got the following error :

[error] Drab Handler failed with the following exception:
** (Protocol.UndefinedError) protocol Enumerable not implemented for nil. This protocol is implemented for: DBConnection.PrepareStream, DBConnection.Stream, Date.Range, Ecto.Adapters.SQL.Stream, File.Stream, Floki.HTMLTree, Function, GenEvent.Stream, HashDict, HashSet, IO.Stream, List, Map, MapSet, Postgrex.Stream, Range,Stream
    (elixir) lib/enum.ex:1: Enumerable.impl_for!/1
    (elixir) lib/enum.ex:141: Enumerable.reduce/3
    (elixir) lib/enum.ex:1919: Enum.reduce/3
    (drab) lib/drab/live.ex:968: Drab.Live.decrypted_assigns/1
    (drab) lib/drab/live.ex:958: Drab.Live.decrypted_from_browser/1
    (drab) lib/drab/live.ex:918: Drab.Live.assigns_and_nodrab/1
    (drab) lib/drab/live.ex:574: Drab.Live.do_poke/5
    (drab) lib/drab.ex:359: anonymous fn/7 in Drab.handle_event/6

Anyone have any idea what this is and how to fix it?

2

I looks like Drab can’t see your assigns. Can you ensure that you’ve changed your template extension to .drab?

3

so is it supposed to be like index.html.eex.drab or index.drab?

4

index.html.drab was the answer.

2 Likes
5

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
1 Like
6

Good idea :slight_smile:

7

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.

1 Like
8

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

1 Like
9

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.

10

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

11

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.
1 Like
12

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.

1 Like
13

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 https://github.com/grych/drab/issues/174

2 Likes
14

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?)

2 Likes