Steffen Deusch

My Team and I are looking for a second senior elixir developer to join us at AZAV Pilot! You’d be joining me in developing and improving our main Phoenix/LiveView SaaS and internal tools.

#ElixirLang #ElixirPhoenix #hiring

P.S. Fluent German is a requirement unfortunately

join.com/companies/az...

I'm shutting down my personal GitHub sponsors in favor of an open collective that will be used to transparently fund Ash related expenses and also contribute financially to projects that matter to Ash & Elixir!

opencollective.com/ash-framework

#ElixirLang #AshFramework

YouTube video by Code and Stuff What's new in Phoenix LiveView 1.1?

Phoenix LiveView 1.1 is out!

Colocated JavaScript (and hooks), list comprehension improvements, and an igniter-based script that makes updating easier than ever.

What an incredible release—check it out!

#MyElixirStatus

youtu.be/EV6DSqTOXM0

Phoenix #LiveView 1.1 is out now! (Actually already yesterday, but we were only able to release the blog post now) #MyElixirStatus

phoenixframework.org/blog/phoenix...

Forgot to post here so... Hello network! It's time for me to move on and I'm kicking off the search for my next role. Let me know if you're looking for someone who obsessively ships, takes on whatever work has the highest impact, and consistently gets feedback like "you're too impatient".

The macro components are planned to be part of 1.2, yes!

We now have an igniter upgrader for anyone using LiveView 1.0.

The RC requires you to first update the dependency and then do

mix phoenix_live_view.upgrade 1.0.0 1.1.0

The final release will allow you to just do:

mix igniter.upgrade phoenix_live_view

Big thank you to @zachdaniel.dev!

We released #Phoenix 1.8.0-rc.4 yesterday and Phoenix #LiveView 1.1.0-rc.3 just now. This should be the final RC before 1.1.0, so please check it out if you can! #MyElixirStatus

This is quite a substantial change, therefore we'd love if you could try out the new RC in your projects and report any problems you find.

We're also very interested in seeing some real world numbers about diff improvements, so please let us know what you see!

github.com/phoenixframe...

The key allows us to efficiently calculate only the changed positions. If entries move without other changes, we can only send the old index. If entries move and change, we send a minimal diff and the old index.

That lead to a quite large PR we shipped in the latest RC.2:

All comprehensions are change tracked now. When there's no key, we use the index to track changes. This means that prepending an item leads to all following items being considered changed, so giving a `:key` is still very useful.

When I started the work on `:key`, I knew that the optimal solution would require a major change to how LiveView handles comprehensions. With the LiveComponent approach failing, I bit the bullet and started to rewrite the comprehension code from scratch.

@josevalim.bsky.social and I tried to make the LiveComponent approach work, but we failed. And with all those problems we'd rather not ship keyed comprehensions at all. Too many strings attached.

Moreover, regular comprehensions disable change tracking for anything inside. Therefore if you rendered a keyed comprehension inside of a regular one, the benefits of the keyed comprehension could also be negated almost completely.

The issue is that due to how live components are handled, those are not part of the usual template sharing. Therefore, if a keyed comprehension rendered a regular comprehension inside, it would send all the static parts for each of the keyed comprehension's entries, leading to very large diffs.

When LiveView renders something inside a comprehension, it knows that any static parts inside are rendered multiple times, so it extracts those into a special "template" section, seen as `p` in the diff. The static parts then only refer to a number in that `p` section.

When testing this inside a bigger component, we found a big problem though: in some circumstances, the diff could actually get much larger than the regular comprehensions. That's because LiveView already had a very good optimization for comprehensions: template sharing.

We knew that LiveComponents were not the optimal solution, but they already got us quite far: instead of sending all entries for a list, we only send the list of component ids and the changes for those entries that changed.

In #Phoenix #LiveView v1.1.0-rc.0 we shipped `:key` support for comprehensions in HEEx. The idea was to finally be able to have change tracking in comprehensions. We did this by leveraging LiveComponents. Sounds easy enough, right? There were some problems though. A thread. #MyElixirStatus

The second RC for #Phoenix #LiveView 1.1.0 is out now with a bugfix for an issue affecting template re-rendering when using `:let`.

I did not post about rc.0 last Tuesday, but it's a quite big release, so please give it a spin and open up issues in the repo if you find any problems! #MyElixirStatus

We're planning to bring it back (hopefully in the more powerful version) in LiveView 1.2!

We don't want to introduce a public API where we're not sure if we'd need to deprecate it soon after.

This doesn't mean that there won't be colocated hooks in LiveView 1.1, those will still be there, but the macro component API that is used behind the scenes won't be made public yet.

So, I recently posted about macro components for #Phoenix #LiveView:
bsky.app/profile/stef...
bsky.app/profile/stef...

We've decided to postpone making MacroComponent a public API in LiveView 1.1, because we're still exploring a more powerful approach: github.com/phoenixframe...
#MyElixirStatus

Release v1.19.0-rc.0 · elixir-lang/elixir Type system improvements Type checking of protocol dispatch and implementations This release also adds type checking when dispatching and implementing protocols. For example, string interpolation i...

Elixir 1.19 is a banger! Honestly I'm so pleased with the direction that #ElixirLang is going. My programs just get faster and more correct every time. I just know that we're in good hands. Thank you to everyone on the team for your hard work!

github.com/elixir-lang/...

You should not think about it as :key being a shortcut for LiveComponents. It’s just a LiveComponent under the hood, but the important part is that it optimizes the diff of the comprehension!

introduce `:key`-ed `:for` comprehensions by SteffenDE · Pull Request #3827 · phoenixframework/phoenix_live_view A keyed for comprehension works by transforming the comprehension's content into a LiveComponent, which will perform change-tracking and optimizes the payload over the wire: <ul> <li...

In the future, this may be optimized further. Of course, another way to handle lists is to use streams, but that's not always the solution.

See the PR for more details if you're interested!
github.com/phoenixframe...

So now, we're adding keyed for comprehensions, which allow change-tracking on variables introduced by for comprehensions, as long as a `:key` is provided. Internally, this still uses LiveComponents, so the diff is equal to when you manually render a LiveComponent for each entry of your list.

A HEEx template with code: ~H""" <ul> <.live_component :for={%{id: id, name: name} <- @items} module={MyListComponent} id={id} name={name} /> </ul> """

One way to improve that right now is to use LiveComponents. Basically, instead of directly rendering the content of the tag given to `:for`, you render a LiveComponent instead, which does perform change-tracking on its own assigns. This is cumbersome though, as you need to define a separate module.

A HEEx template: ~H""" <ul> <li :for={%{id: id, name: name} <- @items} :key={@id}> Count: <span>{@count}</span>, item: {name} </li> </ul> """ Notice the special `:key` attribute.

One common pitfall when using lists in #LiveView is that they are not change-tracked. We might have something to improve that situation in an upcoming update! #MyElixirStatus #Phoenix #ElixirLang