This is not a restriction! This is the result of an algorithm that transforms the AST into an equivalent AST with the variable bindings at the top. The goal is for the user to write a normal template (the template above) and all the rest is done by the template compiler. The goal of having this complex compilation step is to remove all restrictions from the templates.
tmbb
josevalim
Creator of Elixir
Oh I see. You are saying templates can be fully compiled in this fashion. That’s an even better idea, yes. I don’t think we need to do this an extra pass, we can probably change the engine to emit this code from the beginning.
1
tmbb
Yes, you can try that. If I were to follow that path (I’ve actually tried to do it for about 30mins or something, and it’s not trivial), I’d do the following:
-
Don’t try to produce a valid expression at all steps. You probably need to keep some context of what variables you have already bound and stuff like that
-
Instead of “folding over a quoted expression” (which is what an engine currently does), fold over a more complex struct (e.g.
%Context{}), which keeps the metadata you need. You do have some experience in writing compilers, so you probably know what you need (NimbleParsec, in particular, is a work of art, although I can’t understand much of the source) -
You’ll probably need some minimal postprocessing anyway.
I can help, but I can’t commit to deadlines: I might have something ready in 1 day or in 1 month. And in any case, I’d like to go the way of rewriting the already compiled template according to a “typical” engine (nothing special, just personal preference).
If you want to try to build the template as you parse the EEx template, I suggest you go that way while I try to transform the already compiled template. In any case, the optimum approach will probably take a bit from both perspectives.
I have a sandbox project named PhoenixUndeadView where I try some approaches. I’ll publish it today or tomorrow so you can see for yourself what I’m doing (not much, currently). I’ve started a topic to sorta blog about it, but most (here), but most of the interesting discussion is in this topic 
5
josevalim
Creator of Elixir
Yup. I think this is the best approach indeed. I am just not sure about the interplay between handle_begin + handle_end and handle_expr but it should be doable. We should probably require Elixir v1.5 too, as doing a metadata approaches requires handle_body which does not exist in earlier versions.
1
tmbb
RANT (tangentially related to what we’re discussing)
The Elixir and Erlang compilers seem to leave out a lot of easy optimizations that other compilers perform (e.g. Java’s bytecode compiler, Haskell, OCaml) perform. I don’t know how big the results would be in practice, but currently it’s a little hard to experiment with Elixir’s compilation, because the compiler doesn’t have any extension points that I know.
It would be interesting to have a some kind of Elixir compiler in Elixir (even if it doesn’t compile directly to Erlang), which could be hooked into certain parts of the compilation pipeline. It would make it easy to perform radical AST rewritings.
0
grych
Creator of Drab
Well, Drab does almost the same, your approach is even better because I replace all the content. Like in this example:
<strong><%= @title %>:</strong><br>
<%= for user <- @users do %>
Username: <%= user %> <br>
<% end %>
After processing with Drab Engine, the html would look like:
<strong drab-ampere="1234"><%= @title %>:</strong><br>
<span drab-ampere="5678"><%= for user <- @users do %>
Username: <%= user %> <br>
<% end %></span>
So in the simple case, when you update @title, it would just update innerHTML of the <strong drab-ampere="1234">, but when you update @users collection, it must update the whole <span drab-ampere="5678">. Doing the diff on the client side is a great idea, and it solves the problem when, for example, system needs to replace the whole form_for and refreshes the <input>s so the value user already set is gone.
In Drab, the server-side data is only updated when the client successfully updates. In the other case, poke returns {:error, description}. Server-side data is rather a cache, I treat client as a data source.
The other issue is a broadcast change. At the beginning, I did not want to build the broadcasting version of the poke, as the browsers may have different data at the same time. But the community convinced me to do it, but it is limited. There were more concepts, like re-sending back to the server changes coming from the other browsers, or send the changes to all Drab servers in the server, but I’ve found them overcomplicated.
3
josevalim
Creator of Elixir
Interesting! This is a big distinction then. I know Chris is exploring some ideas and I have some thoughts as well. My latest idea is to store only “params” on the client and you can update those parameters with LiveView. So for example, if you want to do something like pagination, you would start with the parameter set to nil (or zero) and every time you change the page you could update the parameters in the client with a data push (or change the URL - but that’s a separate discussion). So you keep in the client only what is necessary to tell the server where it was. Not much different from the usual request/response life-cycle.
Thoughts?
Agreed. It is always tricky, especially if you consider what will happen on disconnects and so on.
2
dgmcguire
I think this problem is a lot less difficult to solve if you keep all of your state on the server. That way when something inevitably goes wrong and the user refreshes their page, every issue is solved from a known good state
edit: well not that you can’t mess up server-side state, but going over the internet is certainly going to expose way more super rare bugs than dealing with your code all running on one node or inside a relatively much more stable local network
3
tmbb
Let’s not lose track of what the goal with Drab or LiveView is: the “gold standard” is always the lovingly crafted client side framework with both custom javascript and server side rendering (it really helps if you’re using JS on the server too). That way you can be smart about which data you send, how to deal with disconnect, etc.
These solutions are not operating on the same space. Drab and LiveView are a kind of a hack to simplify development (at least LiveView was explicitly presented as such).
If you start to have a smart client and at the same time the ability to push changes from the server, you now have a distributed system and your code is automatically orders of magnitude more complex for things to work.
2
grych
Creator of Drab
That would simplify the implementation, but IMO is not enough. The power of living assigns (LIveView, Drab.Live) is that you can do everything what you could do with normal action in the controller, but live.
IMO is more difficult - vide: handling disconnections.
Now, I have a drab genserver linked with channel process. In case of disconnection, it just dies, I don’t care about cleaning up stuff etc. After reconnect, new process gathers the data from the client, so if anything were changed before disconnection, we have it in a new process.
Keeping on the server means that your data must persist the disconnection. So you need to keep it somewhere, handling timeouts. For me that was more difficult!
2