This is correct—it is a conceit they are using to keep the examples focused to the “lesson” at hand: learning Liveview; and to leave “room to grow” the examples with later functionality.

@mindok’s posts concerning module attributes are the idiomatic approach to this! But you can see why introducing those patterns don’t serve what is being taught: instructive writing can be weird like that sometimes.

Probably a more common alternative in Elixir would be to use module attributes. e.g.:

@title "Product Ratings"
@subtitle "Average star ratings per product"
@x_axis "products"
@y_axis "stars"

  defp assign_chart_svg(%{assigns: %{chart: chart}} = socket) do
    socket
    |> assign(:chart_svg, render_bar_chart(chart, @title, @subtitle, @x_axis, @y_axis))
  end

Ya, what @mindok said. I have have barely read any of that book so maybe there are going somewhere with it and will flesh it out later? Wrapping strings in functions as a general rule certainly isn’t a “thing” though. I’ve never done it and this is the first time I’ve seen code that does it (I’ve been doing Elixir for around 5 years).

From what I have read of the book, though, they do extract far more than I personally care to. There are lots of small single-user private functions that don’t really read any better than the bare code in my view. I’m not implying the book is bad by any means (how could I know? …and all of Sophie’s stuff I have read and watched is amazing) and while idiomatic Elixir is certainly a thing, it’s not super obsessive and people have varying styles.

EDIT: One reason I can think of to use functions is that heex overloads @ to access assigns. So if you have

@title "Product Ratings"

def assign_thing(socket) do
  assign(socket, :title, @title)
end

def render(assigns) do
  ~H"""
  <%= @title %>
  """
end

That reads super confusingly because the @title in the render function is referring to :title in the socket, not the module attribute @title.

That’s total guess, though.