I have a question about liveview. I currently have something in my router like
scope "/" MyAppWeb do
pipe_through :browser
live "/link", MyLiveApp.Index
live "/link/:id", MyLiveApp.Show
end
and inside of my index.ex I have something like
def link(assigns) do
~H"""
<.link navigate={~p"/link/#{@link}"} link={@link}>
"""
end
In my show I get the param link getting sent through but is there a way to pass all the information through that is contained in link say a struct %Link{id: 123, "url": "https://google.com"} or do I have to just send the id and refetch the data?
The client will be able to see those params in the link, of course. If for some reason you wanted to hide the information from the client you would be better off storing it in the database.
If i had say a list of movies e.g. The Matrix, Matrix Reloaded, etc and in my initial route (/link) I would render all the movies w/ all information. Can I not just pas down The Matrix and all data initially fetched for “/link/the_matrix” or I will need a refetch?
It depends on how you’ve architected your LiveView.
If you have one big LiveView, you can use patch={...} instead of navigate to patch the current LiveView. You can then conditionally render just one movie instead of all of them, call out to components, etc.
If your “all movies” and “one movie” routes are separate LiveViews, then you need to re-fetch the data as you say. I would not pass this information via query params, as that would be abnormal (and would allow for weird injection behavior).
Both of these approaches are valid and you would choose one based on your requirements. See Live Navigation.
No, it’s the LiveView module that your router points to. Like:
live "/movies", MyAppWeb.MovieLive, :index
live "/movies/:id", MyAppWeb.MovieLive, :show
live "/whatever", MyAppWeb.MovieLive, :whatever
That last atom will be passed to handle_params and available as @live_action, see the docs.
You will have to architect the LiveView to understand which route it’s on (using @live_action and the assigns) and conditionally render whatever it is you want to show.
That would be the “second” option I showed. Each route points to its own LiveView. If you want to keep that approach, you should re-fetch the data from the DB.
Fetching an entire list of movies should be paginated anyway and even a single phoenix instance with a cheap DB will be able to serve several hundred requests per second most likely.
If you check your logs while developing, you will see the response times of your requests.