This preloading example from the docs demonstrates how to avoid an n+1 query, which the stream example from the blog posts accomplishes by calling Blog.list_posts() that likely looks something like def list_posts(), do: Repo.all(MyApp.Post).

So in this case, preloading database resources into socket assigns may well be unnecessary/superfluous since these resources have already been added into the socket streams. And since one of the big advantages of streams is to offload storing of collections in memory on the server, I would think twice about about preloading and storing these same collections in memory on the server via socket assigns when using streams.

I haven’t tested it, but this could be one way of passing streams into multiple LiveComponents via assigns.

defmodule DemoWeb.PostLive.Index do
  use DemoWeb, :live_view

  alias Demo.Blog
  alias Demo.Blog.Post

  @impl true
  def mount(_params, _session, socket) do
    {:ok, stream(socket, :posts, Blog.list_posts())}
  end

  ...
end

# index.html.heex
<%= for post <- @streams.posts do %>
  <.live_component module={PostComponent} id={post.id} post={post} />
<% end %>

On another note, the following section of the Phoenix.LiveComponent docs on Preloading and update might help in understanding what @josevalim is saying.

So on first render, the following callbacks will be invoked:

preload(list_of_assigns) -> mount(socket) -> update(assigns, socket) -> render(assigns)

On subsequent renders, these callbacks will be invoked:

preload(list_of_assigns) -> update(assigns, socket) -> render(assigns)

Since you need the socket to pass into the stream, stream_insert, or stream_delete functions, only the mount and update LiveComponent callbacks can interact with streams.