Can we use `Phoenix.LiveView.live_link_info!/3` without fear it's going to be made effectively unavailable in the future (private or whatever)?

Phoenix Forum Questions / Help
1

The question is for the LV core team members only.

I need to know if I can depend on this function for taking out all the params (including the ones in the path) from the URI. The alternative is passing along (in my code) both the uri and the params which is mostly redundant and I’d like to replace it with the call to the stated function, but I need to ask because this function is not documented in the API docs.

Thanks!

2

Wasn’t it easier to ask in the repo issues?

3

Of course it was, but it will be the last resort if I don’t get an answer here (because it’s not a bug and not necessarily a design/docs flaw either but probably intentional)

4

Passing those values down is intended to be done though. Working around the system of passing assigns down explicitly means that the values cannot be tracked for changes and therefore cannot be updated if they change.

Also live_link_info! is private API already (@moduledoc false on the module). So it’s not intended to be used by users of the library.

1 Like
5

Passing those values down is intended to be done though. Working around the system of passing assigns down explicitly means that the values cannot be tracked for changes and therefore cannot be updated if they change.

Honestly, I don’t understand why. It’s not like a params map has any more info than it’s already contained in the uri it is constructed from, it’s just just that it’s structured differently i.e. the params have been extracted.

Essentially params is a subset of URI in terms of the information it carries.

6

I am saying this in respect to “values cannot be tracked”. They are tracked as a whole, just as if the entire params map is assigned.

7

I read your request as if you don’t want to pass down either information.

If you have just the URI you can already use public APIs to do 95% of what live_link_info does using Phoenix.Router.route_info as well as Plug.Conn.Query.decode.

1 Like
8

Actually, it’s precisely the function in question that gives me all the data that I need - both the query params and the params extracted from the path treating them equally, the catch being I feel it’s redundant to send/assign along the uri itself only because I also need its relative path. Yet, I’d like to send/assign a standard structure instead of just taking its path string and send it with the params map (thus again either having two args/assigns or having to structure a struct that contains them both).

Alternatively, I could just send/assign the relative URI.t() and then write my own code that extracts the params from the path (or copy it from the function in question), but I prefer reusing the function that already exists if anyhow possible.

9

That’s the way to go. live_link_info might exist, but not for your usecase. It iirc used for validating links you use with live_navigate and such and therefore has different (futher) constraints to handle than what you’re looking for. There could be a number of reasons for live_link_info to change, which you wouldn’t care for at all.

1 Like
10

So it begs a question… How about LiveView exposing a helper function that only does the params extraction (both query and from the path) and is then used by the non-public API live_link_info functions and can also be used by the users?

Not saying it’s a must, but it’d be nice to use the exact same logic without need of replicating it.

11

Maybe you should propose addition of a similar function in the public API section?

2 Likes