ydd
Mount vs handle_params on the LiveView life cycle
Hi all,
I’m a bit confused about the role of handle_params in the LiveView life cycle. I’ve read Phoenix.LiveView — Phoenix LiveView v1.2.5 many times and I still don’t understand it, hopefully someone can clarify.
Let me lay out what I understand from the docs:
mountis called twice, once on the initial HTTP request and again on the websocket connect. (BTW the docs read “once per LiveView life-cycle” which is quite confusing).handle_paramsis called aftermount, meaning it’s also called twice.- Both
mountandhandle_paramstake the same arguments and trigger a render.
The docs suggest we should load data in mount as it’s called once and mention handle_params is used to handle live_patch operations showing the following example:
def handle_params(params, _uri, socket) do
socket =
case params["sort_by"] do
sort_by when sort_by in ~w(name company) -> assign(socket, sort_by: sort)
_ -> socket
end
{:noreply, load_users(socket)}
end
load_users(socket) is not listed but it implies it’s a function that load the users from somewhere and sorts it using sort_by. Assuming we’re also loading data in mount wouldn’t that mean the loading is happening twice?
If handle_params is called regardless, takes the same arguments as mount, and is invoked on live_patch whereas mount is not, why not always load the content there instead of in mount?
Are we supposed to avoid loading if some elements are already present in the socket.assigns from mount?
It may be that I’m misunderstanding something but I’ve been confused about this for a while.
Thanks in advance!
Marked As Solved
josevalim
You would load it on mount OR in handle_params.
The golden rule is: always load data on mount. But if you add live navigation with live_patch, the data that can be changed on-the-fly must be now loaded on handle_params.
Also Liked
LostKobrakai
If you want SEO and/or a working website without javascript you’d need to load stuff for both renders. The HTTP request and the websocket connection are completely separate connections (by time as well as type) so you cannot simply keep state around on the server. If those points are not relevant you can just load stuff for the websockets connection and make the static render return just a loading screen.
LostKobrakai
I’m of the opposite opinion. Often times SPAs are used because the page needs e.g. live update or lazy loading of a list of items. If things start to fail on the client side (for whatever reason) you’re often left with nothing. Many of them could show a lot of useful information if they would have a static render or even fall back to e.g. plain old pagination links if the fancy js lazy loading does fail.
josevalim
Your snippet is correct.
the params that can change are loaded on handle_params.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








