Good idea. I submitted it. Thanks again.
piex
domvas
Hello,
I adopted Drab recently, and i’m facing a problem (surely some kind of noob problem though):
How can I test commanders?
I used to test all my controllers, and have some controller-related code untested made me feel uncomfortable.
I suppose it is close to channel test (and I only work with channel when I go through Phoenix book…) but I don’t have any clue what to send to socket.
Or maybe, this should be tested via headless browser like any front end?
Tanks your your help!
grych
Creator of Drab
There is no support for tests in Drab yet. It must be done in the way to the stable production version, but I still have no idea how could it look like 
In internal drab tests, I am doing a full integration tests with hound and chromedriver. Unfortunately, the headless browser (phantomjs) does not want to work with Drab.
thib
Hello Grych
I get a protocol Enumerable not implemented for nil while using the Drab.run_handler method on Phx 1.3. I try to reproduce your example but get the error bellow. Any suggestion ?
<a class="waves-effect waves-light btn grey" onclick="Drab.run_handler('click', 'clicked', {click: 'clickety-click'});">
def clicked(socket, payload) do
socket |> Drab.Browser.console("You've sent me this: #{payload |> inspect}")
end
Transport: Phoenix.Transports.WebSocket
Parameters: %{"event" => "click", "event_handler_function" => "clicked", "payload" => %{"click" => "clickety-click"}, "reply_to" => "8a0affa7-1dd2-4e9d-95d8-9441897eb747"}
[error] Drab Handler failed with the following exception:
** (Protocol.UndefinedError) protocol Enumerable not implemented for nil. This protocol is implemented for: ...
I also receive this after closing the alert box :
[debug] INCOMING "execjs" on "__drab:same_path:/packs/1" to Drab.Channel
Transport: Phoenix.Transports.WebSocket
Parameters: %{"ok" =>["SFMyNTY.g3QAAAACZAAEZGF0YWgCZ2QADW5vbm9kZUBub2hvc3QAAA6mAAAAAAByAANkAA1ub25vZGVAbm9ob3N0AAAAj__RLAABgxyz62QABnNpZ25lZG4GAAPPMjNfAQ.2KVP7lyR4fOT_q4tZNBGdCA3dzZFZX5fXWMV_gc-Xjg", nil]}
grych
Creator of Drab
It’s a bug. Thanks a lot for reporting!
Could you please create an issue on github, so we will have all bugfixes in the one place.
thib
grych
Creator of Drab
v0.6.0-pre.1 finally arrived
Girls and boys,
after a long time, I am happy with the brand new Drab EEx engine, completely rewritten, shorter, faster and way more clever. It is finally not pushing <span> in every corner of your html template, but it is using the existing tags.
Please help me with testing this one.
- add
{:drab, "~> 0.6.0-pre.1"}to your deps inmix.exs mix deps.getrm priv/hashes_expressions.drab.cache.*(it’s been renamed todrab.live.cache)mix cleanto recompile templates
Changes
The main change in the new template engine is that now it is not injecting <span> everywhere. Now, it parses the html and tries to find the sourrounding tag and mark it with the attribute called drab-ampere. The attribute value is a hash of the previous buffer and the expression, so it is considered unique.
Consider the template, with initial value of 1 (given in render function in the Controller, as usual):
<p>Chapter <%= @chapter_no %>.</p>
which renders to:
<p drab-ampere="someid">Chapter 1.</p>
This drab-ampere attribute is injected automatically by Drab.Live.EExEngine. Updating the @chapter_no assign in the Drab Commander, by using poke/2:
chapter = peek(socket, :chapter_no) # get the current value of `@chapter_no`
poke(socket, chapter_no: chapter + 1) # push the new value to the browser
will change the innerHTML of the <p drab-ampere="someid"> to “Chapter 2.” by executing the following JS on the browser:
document.querySelector('[drab-ampere=someid]').innerHTML = "Chapter 2."
This is possible because during the compile phase, Drab stores the drab-ampere and the corresponding pattern in the cache DETS file (located in priv/drab.live.cache).
Sometimes it must add a <span>
In case, when Drab can’t find the parent tag, it injects <span> in the generated html. For example, template like:
Chapter <%= @chapter_no %>.
renders to:
Chapter <span drab-ampere="someid">1</span>.
Avoiding using Drab (nodrab option)
If there is no need to use Drab with some expression, you may mark it with nodrab/1 function. Such expressions will be treated as a “normal” Phoenix expressions and will not be updatable by poke/2.
<p>Chapter <%= nodrab(@chapter_no) %>.</p>
In the future (Elixir 1.6 I suppose), the nodrab keyword will be replaced by a special EEx mark / (expression will look like <%/ @chapter_no %>).
The @conn case
The @conn assign is often used in Phoenix templates. Drab considers it read-only, you can not update it with poke/2. And, because it is often quite hudge, may significantly increase the number of data sent to the browser. This is why Drab treats all expressions with only one assign, which happen to be @conn, as a nodrab assign.
piex
I am working on a small experimental app that incorporates geolocation into an interactive chat experience. I want the LiveCommander to not only have lat/lon available in @lat/@lon variables, but also be able to respond to GeoLocation changes and update the page with fresh info that is location specific. I could do some JS code that somehow combined Geolocation.watchPosition()) with sending info to a phoenix channel to update the phoenix session, but am wondering if there is better way to incorporate geo position changes with LiveCommander, some sort of drab-event that could be created, or some other way to do it that fits the drab model better.
grych
Creator of Drab
Drab does not have any geolocation helpers (maybe it is a good idea to add it in the Drab.Browser?).
To archive your goal, you may call javascript function (from Geowatchin.watchPosition()) Drab.run_handler() to execute function in the commander module directly from the browser.
jrobn
I’m surprised pheonix doesn’t have something like this built-in. It appears to be the perfect fit for the strengths of Elixir and Pheonix while not being the same JavaScript SPA hell that is currently out there. It’s exhausting.
With polish, Drab could be a viable way to build rich applications on the server side that appear to be client side in the browser.
I think this approach should be a default option in Pheonix!
Great work btw, @grych