This is true, actually Drab is quite mature, because it’s been born in the long discussions in this forum.

• small reads and updates of DOM (Drab.Element, Drab.Query)
• quick access to the browser-specific attributes, like a local timezone (Drab.Browser)
• Drab.Modal, which is IMO a killer feature as it actually hold on processing and waits for the user input
• Drab.Waiter, which does the same but more general, without a modal
• and, last but not least, ability to calculate using browser (exec_js(socket, "2+2"))

So after reconsideration I am going to move Drab to the v1.0, as it is just a few steps ahead, and a lot of code for this is already done. I hate wasting good code. The project will be supported (bug fixes) as long as people are using it, but no new big features will be developed by now (sorry @OvermindDL1, no token via cookie, as I want to wait to see how Chris will cover this, but we may think about building our own transport as it would be easier since phx1.4).

Then I will take a break and will see what will born as a LiveView. If, as I assume, it will be a huge success, I will give up Drab.Live and Commanders and adopt rest of the Drab features to the LiveView, using its event handler API (phx-click attributes). Which accually I like more than mine, I probably overcomplicated stuff with Commanders, but have some concerns if it can cover some cases.

I really hope @chrismccord works with you on LiveView. You’ve definitely pioneered and popularized this entire concept within this community.

I don’t know if it is helpful, but this is how Drab does it. In compile time:

• it has its own EEx engine
• during compilation the Drab EEx, while handle_expr, it is checking if there are any assigns inside the expression
• if there are assigns, it is injecting the special attribute (drab-ampere), to the parent tag; if there is no parent tag, it is surrounding the expression with the <span>
• injecting the attribute also checks if the assign is in the tag body, or in the attribute
• there is a special mark, <%/ %> which marks expressions which should not be ‘drabbed’
• at the end, it collects all amperes with the corresponding assigns; this is how it knows where to change if you update the assign in a runtime
• assigns are stored in the frontend, Drab injects javascripts like window.__drab.assigns.myassigns = <%= @myassign%> to the template

In a runtime:

• you render the template as usual, with the controller
• on connect, Drab gets the current assign values from the frontend and cache it in the genserver
• on any assigns change (called poke), Drab re-renders the template on the backend; because it know exactly where in the template the assign you are changing is begin used, it gets the value of the tag body (or the attribute value) with Floki
• then it sends the JS back to the browser - it is a simple update of the specific tags only
• it also sends back the new assign value to the browser - this is important, because in case of disconnect the Drab genserver is killed

There are also corner cases, like a special treatment for @conn, or keeping the csrf token in case you update the whole form, or detecting which ampere to update in case they are nested.

All the above looks complicated, but this was the only what I could invent with the assumptions that:

• you do not require many changes to the existing phoenix project: in this case the only change is the extension from *.eex to *drab
• it must be beginner friendly (to convince beginners who are scared of Ajax and JS)
• it must work as expected, be intuitive (this is why assign values must survive disconnection)
• all must be archived with external library only, without any changes to Phoenix (as they are not very welcomed)

Awesome keynote Chris!

Loved hearing about LiveView… and this bit made the hairs on the back of my neck stand up

38982×450 132 KB

“Challenge the status quo of what is possible”

“We have this platform that can advance the state of the art”

“The future is ours to build”

Although we’ve seen similar patterns before (i.e. drab) LiveView still totally blew me away and I’ve rewatched the video 3 times now. Now tomorrow morning I get to write tons of React form validation code and repeating the same/similar code in my changeset validations on the server and dealing with all the plumbing… while thinking how much easier it would be with LiveView with no perceptible performance degradation.

The way it was presented it seems like you could make LiveView “components” (stateful and stateless (not needing a GenServer?)) and hook them together like a React component tree. It seems weird to say but maybe we could have “JSX-like” syntax inside the EEx LiveView components which could call other LiveView module’s render functions with props (assigns) and children. All the data would be accessible server-side so less need all the JSON/GQL requests. It seems like that should work… and it could be the right choice for many (not all of course) project types.

Unbelievably incredible job @chrismccord just can’t wait until it is released for experimentation!!