chrismccord

chrismccord OP

Creator of Phoenix

fixed. Thanks!

3
Post #14
ianc

ianc

This is great news, already updating!

Any tips for converting routes from the non-verified format to the ~p verified routes sigil? I have about 700 route calls in my code-base to convert :grimacing:

Update: I see this note about updating routes under “Optional updates” in Upgrading from Phoenix v1.6.x to v1.7.0

While these changes are a big step forward for new applications, it probably makes sense to maintain your current application conventions and skip these steps for established, large 1.6 applications.

4
Post #15
BradS2S

BradS2S

I never thought I’d get this excited about streams. I don’t even like to fish..

5
Post #16
Eiji

Eiji

and in example/generators:

Blog.list_posts/0 calls Repo.all/1 which then fetches all records, right? The stream/3 even calls for on said collection (to add generated dom_id and -1 index to a new Tuple). Where we win here when talking about stream?

From what I can see using Repo.stream/2 instead of Repo.all/2 would not give us much as per mentioned for call that returns a List, right?

I guess that after rendering said (empty) table the live stream is rendering one row at a time and sends the DOM to JavaScript which is then appended to table element, right?

So let’s say I have 1 million database entries and I want to stream them using Repo.stream/2 only when needed to have infinite scrolling. Can I do so with this new API?

2
Post #17
josevalim

josevalim

Creator of Elixir

The win for streams will come when pushing updates to LV via PubSub. It is not in the generated code but streams get us closer to that and adding the remaining PubSub bits should be easy.

11
Post #18
aiwaiwa

aiwaiwa

I can confirm that I was successfully able to modify several items at once, may be not in a very efficient way, within one handle_info callback and they seem to arrive as one update to the client. This is what I did. I need to modify checkbox selections of several items at once:

socket = Enum.reduce(cells, socket, fn c, acc -> stream_insert(acc, :cells, c) end)
{:noreply, socket}

Unfortunately, in my case the payload is around 8K-14K per each round. I’m blaming Heroicons as they get included as inline svg. I show them by “if”, but I also tried “ifing” hidden / block CSS class to a surrounding div and couldn’t achieve any better results yet. Still playing.

Edit: There’s also Edit & Delete links with JS coming for each updated row - another source of a heavy bandwidth. Plus Tailwind class names, as now they are also part of each message. I think this will at some point require attention, I just don’t want to prematurely optimize while sketching the app.

4
Post #19
BartOtten

BartOtten

@chrismccord Is there a known show stopper for Phoenix to send the static segments of components only once? Then over the lifespan of a session a user would build ‘a library of components’ and only dynamics have to be send for each component which was sent earlier in the session. Especially useful with rows.

Asking directly as you went to great extend to minimize data over the wire so maybe you have thought of it earlier and know the answer already.

—-

…and next we request to prebuild the component lib for CDN etc etc. One step at the time…

3
Post #20
chrismccord

chrismccord OP

Creator of Phoenix

I tried to cover this in the writeup, but even ignoring the PubSub use case, we get huge wins with streams in phx.gen.live compared to the 1.6 approach. We used to push_navigate back to the PostLive.Index LV when you submitted the modal form, which would require refetching the entire listing every time you created or edited a post. Now with streams, we can push_patch back to the index LV and stream_insert the created or updated post. No extra fetching of the listing required.

Our generated context functions have nothing to say about how you’d handle pagination, so this is a little tangential to our generated code. But LV streams could absolutely be used to do “realtime feeds”, especially because you can prepend or append (or insert any any place) on demand. Hope the helps!

12
Post #21
ajur58

ajur58

Awesome job Chris & Team, been looking forward to this release for long! Exciting stuff! The wait wasn’t too bad though as the rc releases were already stable enough for me :slight_smile:

1
Post #22
josevalim

josevalim

Creator of Elixir

Not really. Stateful Phoenix.LiveComponent already does this and we can generalize it. The problem is the API with how the user can opt-in to this, because it requires tracking what was sent on both client and server (only the keys), so it is definitely not something we want to do for everything automatically.

Or alternatively we figure out a mechanism to send them as regular images and we let the browser cache do its thing.

3
Post #23