Maybe you could provide a way to tag certain processes as important so those would continue to run while other less important processes could die?
l00ker
grych
Creator of Drab
That makes sense. Some functions may become tasks. And in this case we are not changing the Drab’s core, but rather extending its functionality.
ltrls
Hello,
I’d like to authenticate my Drab socket using Guardian (so I can get the current user in commanders via Guardian.Phoenix.Socket.get_resource/1, for instance), but both Drab and Guardian work by “overriding” the connect callback, so it doesn’t work. Am I doing it wrong?
I’m surprised that I don’t seem to find anyone else having stumbled upon this problem.
(thanks for the great work on this library anyway, so far it’s been a pleasure to use!)
grych
Creator of Drab
Hi @ltrls,
This is true: Drab steals connect callback and therefore, you can’t use your own.
This must be changed, as not only Guardian is the victim. I am still thinking how to change it. The sooner I do it the better, as it will require all existing application to change their user_socket.ex.
There is also onconnect callback in the commander, and I was thinking to change it so it could modify the socket with Guardian.Phoenix.Socket.authenticate/3 there, and return {:ok, modified_socket}. That would be a little bit more work for you, as you need to do it in each commander, but maybe it would be good to have the authentication per commander?
grych
Creator of Drab
Hi all,
In the current version, the only you need to do in your user_socket.ex is to use Drab.Socket. I made like this, because I wanted to simplify the installation procedure, but it was a bad decision, and this is why Drab is not compatible with the other libraries, like Guardian.
From 0.6.4, you could use the following snipped instead of use Drab.Socket:
channel "__drab:*", Drab.Channel
def connect(payload, socket) do
Drab.Socket.verify(socket, payload)
end
Drab.Socket.verify is going to return {:ok, socket} or :error. The socket is modified with Drab-specific assigns, so if you want to use it with the other libraries, do not forgot to pass the returned version of it:
{:ok, socket) = Drab.Socket.verify(socket, payload)
Guardian.Phoenix.Socket.authenticate(socket, MyApp.Guardian, payload["token"])
[edited because I realized that I don’t have to change the API, but rather to extend it]
ltrls
This seems like the best way! If we can still use use for simple setups, or write the connect callback ourselves to compose functions in it, you don’t even break projects relying on use 
grych
Creator of Drab
There will be one more thing to change, if you want to pass the external token connect/2 callback: you will need to pass the token somehow from the client. In this case, instead of adding the following to app.html.exs:
<%= Drab.Client.js(@conn) %>
(which BTW I just renamed to Drab.Client.run), you should generate Drab client’s code first, and connect with additional parameters then:
<%= Drab.Client.generate(@conn) %>
<script>
Drab.connect({auth_token: window.my_token});
</script>
There is also the third way pass the token via Drab.Client.js/2 as additional assign, like:
<%= Drab.Client.js(@conn, my_token: token) %>
In this case socket returned by Drab.Socket.verify/2 would contain it as an assign, so you may authenticate like:
def connect(token, socket) do
{:ok, drabbed_socket} = Drab.Socket.verify(socket, token)
Guardian.Phoenix.Socket.authenticate(drabbed_socket, MyApp.Guardian, drabbed_socket.assigns["my_token"])
end
grych
Creator of Drab
v0.7.0 is out
Possibility to provide own connect/2 callback for socket authentication, etc
Previously, Drab intercepted the connect/2 callback in your UserSocket. Now, there is a possibility to use your own callback:
defmodule MyApp.UserSocket do
use Phoenix.Socket
channel "__drab:*", Drab.Channel
def connect(params, socket) do
Drab.Socket.verify(socket, params)
end
end
Use of the custom marker “/” in Drab templates
This version allow you to use of <%/ %> marker to avoid using Drab.Live for a given expression. The expression would be treaten as a normal Phoenix one, so will be displayed in rendered html, but Drab will have no access to it.
<div>
<%/ @this_assigns_will_be_displayed_but_not_drabbed %>
</div>
Changed event definition core
The existing syntax drab-event and drab-handler attributes does not allow having multiple events on the one DOM object (#73). This form is now depreciated and replaces with the brand new, better syntax of:
<tag drab="event:handler">
Now may set more event on the single object:
<input drab="focus:input_focus blur:input_blur"
or:
<input drab-focus="input_focus" drab-blur="input_blur">
Event shorthands list is now configurable
By default, you can use only few arbitrary-chosen shorthands for the event name / handler name (drab-click="clicked") attribute. Now you may configure the list with :events_shorthands config.
See #73.
Style changes:
- source code formatted with 1.6.0
- use
@impl truein behaviour callbacks - started annotating all functions with
@spec(so far only few) - small style improvements suggested by Credo
Depreciations:
Drab.Client.js/2becomesDrab.Client.run/2drab-eventanddrab-handlerattributes combination replaced bydrab
OvermindDL1
WHOOO! Been awaiting that!
Nice QoL.
I especially quite like this syntax. It’d be nice if you could support this too:
<input drab="focus:input_focus(42) blur:input_blur()" />
So 42 would be appended to the end of the argument list of input_focus (so it should be the normal callback arity + 1) as that’d allow us to easily pass in context sensitive information per call in addition to the event and such as well. Plus I think requiring () on event callbacks are all around better as that leaves it open to not using () meaning that it is a reference to something else for example.