Accessing parameters in LiveView.Socket

Phoenix Forum Questions / Help
1

For complex reasons (yes, I know this is the prototype of an “X Y problem” but I’m just trying to find out what is the simplest thing that would work without too many changes to existing code) I need to access the %Phoenix.LiveView{}.assigns in a helper function. That helper funcion needs to be able to handle a number of cases depending on whether it’s an initial render, a diff, a change to a different liveview, etc.

Currently, I’m doing this:

defp update_params(params, socket) do
    # Fill in the parameters of the path by looking them up in the socket.
    # There is a couple cases we must handle.
    # I think these cases are exhaustive but I'm not exactly sure
    # as I'm intimately familiar with the intrincacies of LiveView.
    # I'm also not sure on whether using the `:__assigns__` or `:changed`
    # fields is using public or private APIs.
    cond do
      Map.has_key?(socket.assigns, :__assigns__) ->
        Map.merge(params, socket.assigns.__assigns__.params)

      Map.has_key?(socket.assigns, :changed) ->
        Map.merge(params, socket.assigns.changed)

      true ->
        Map.merge(params, socket.assigns.params)
    end
  end

The goal is to merge the parameters in the socket assigns (which might have a number of different forms depending on what exactly is happening) with the params given as argument.

I’m pretty sure I shouldn’t be doing what I’m doing above, because the :__assigns__ and the :changed keys don’t seem to be documented as public.

Is there a portable way of accessing the parameters of a socket?

2

Can you talk more about where you are using this helper function? The normal way to do this is to use handle_params/3 and then just assign what you need inside that code.

3

Actually I can’t say much more about it. It’s a little function, deep into the Backpex, which I’ve had to modify slightly in order to make things work for my own uses. So it’s basically an edit to code I haven’t written, which I don’t fully understand based on blinding chasing error messages. I understand this is not the most helpful response, but that’s why I framed the question the way I did.

I was just trying to make sure his little one go work without having to understand how the function relates to handle_params() (if at all). Maybe @Flo0807 (one of the authors of Backpex) could help with some context? I have submitted this change as a “provisional” PR on Backpex’s repo and I’m now looking for a way to do something like this portable