+1
I like the idea, but I will leave parenthesis optional, but enforce using it in examples and docs.
grych
Creator of Drab
pillaiindu
Hi @grych, thank you for the nice package!
There is an idea in meteor framework called latency compensation. I like that idea a lot.
Following is the difference between the old-school ajax way and the meteor’s way (latency compensation) for a request-response-update cycle (copied from the linked post).
This method is also great for chat systems, where a user experiencing latency (of a second or so) because of her/his slow connection may be an unpleasant experience which can be eliminated by the usage of latency compensation.
I think copying the latency compensation from meteor will be very easy for Drab which already uses local-storage and session-storage.
grych
Creator of Drab
Hey, thanks for pointing this!
Anyway, I don’t think it could work with Drab.
All the work is done on the server side. So there is no way that Drab client side JS can simulate the result of any action, as it could literally be anything.
We could allow user to register some JS callbacks launched at the event, so you could develop your own simulation and set up some value immediately, before server returns the real value. I just don’t like the idea: the whole concept with Drab was to get rid of javascript.
But it is true, the latency is an issue from UX point of view. This is why click event senders are disabled by default until the response comes back. Just a one trick, but makes a difference.
gon782
I think the way it stands you can implement optimistic updates (the actual name for this behavior as far as I know) on a case by case basis considering most of the work is in replicating the data model on the client and the server. Making a library that is supposed to sit alongside Drab and that could facilitate that would probably be the way to go. It’ll allow Drab to do what it does and focus on what it’s made for while also possibly allowing for extending the use case for Drab in the future if this other library advances enough.
grych
Creator of Drab
###What if we could write the optimistic updates on the server side, using Elixir and Drab.Element-like DSL?
optimistic_before :save_data do
set_prop "#name", value: "...processing...", disabled: true
end
def save_data(socket, _sender) do
set_prop socket, "#name", value: Database.get_name()
end
optimistic_after :save_data do
set_prop "#name", disabled: false
end
optimistic_before must compile to javascript, which is not so complicated, as set_prop/2 is simply translated to JS "Drab.set_prop(#{encode_js(selector)}, #{encode_js(properties)})". This JS would be sent to the browser on connect, and register to run before and after the event.
OvermindDL1
You could also use that one Elixir->Javascript library too to compile the inner AST to javascript for more unknown expressions too.
grych
Creator of Drab
Yes, I’ve already been thinking about integration of ElixirScript. Is there any other transpiler than Elixir Script?
OvermindDL1
pillaiindu
Looks like my dream (of having latency compensation in Phoenix apps) through Drab is possible! 
jschoch
For those interested:
example of drab under and umbrella with a non-drab app routing non-wss traffic by host
https://github.com/jschoch/drab_umbrella_example
Please comment if there is a better way to do this and if there are any more maintainable ways to route sockets around.