Hi!
We want to know why livecomponent mount/1 socket is empty. Shouldn’t be the same socket passed through when invoking it from liveview parent?
We’d like to use livecomponent mount to assign initial component state, but we need some info like current user_id.
We thought that info would be available on socket but it is empty.
We could move the logic to the preload or update methods, but then, the functions will be called in each update instead of being called only at the beginning.
So, what is the purpose of livecomponent mount if you can’t access to any contextual data?
4 Likes
You can get the current user using the session instead.
@impl true
def mount(_params, %{"user_id" => user_id}, socket) do
{:ok, assign_new(socket, :current_user, fn -> Accounts.get_user!(user_id) end)}
end
About assigns from the parent components, I think it is better to pass it directly(like React and or Vue.js does)
live_component(socket, MyAppWeb.ModalComponent, :assign1: "bla", assign2: @assign2 )
So that way you can pass only what is needed to the child component, keeping it lightweight.
But, no sure if we should do that db call on every child component. Perhaps, it is better to pass user details as assings to child components.
Yep, the problem in the component is the only place where you have that id is in update or preload functions, so you need to add extra logic to only perform queries once.
If we had the assigns available in mount we didn’t have to take care doing extra request on updates.
Did you evaluate if you can have a child template instead of another component?
<%= render "child_template.html", assigns %>
Great question.
Initializing anything useful can only be done in update/2.
mount/1 needs (readonly) access to “parent” assigns to become useful.
I have spent many hours finding a solution without any success.
Please update when you find something.
2 Likes
I am also in that same state. Needing to retrieve useful information from the main liveview to my live_component that has mount / 1
you are aware that you can copy the state from parent to child (using assign) ?
(and have as many copies of the parent assigns as you have children LiveComponents)
what you can’t do is read the parent state once while mounting and translate (some of) the parent state into an independent child state.
(we would want that of course)
2 Likes
Yes, but i thought about the same possible scenario that you covered, about mount and convert the parent state into an independent child state. That concept would be interesting 
1 Like
I just proposed a (maybe) possible solution here:
https://groups.google.com/forum/#!topic/phoenix-core/8970U8QhywY
Let’s see what happens.
3 Likes
So @josevalim has some serious concerns about potential issues when using contextual data that is not change tracked within the LiveComponent.
2 Likes
I feel like this should be documented somewhere
Agreed. Intended use is kind of a black box.
Does anybody know if this is going anywhere? What have you been doing to solve this limitation?
I feel that perhaps the best solution would be passing the initial assigns as “params” to the live component mount callback. This way we won’t have to make any promises about making it “consistent” by keeping track of it. I think that this solves partially some of the concerns @josevalim had on the thread and addresses the point that those “params” are correct at that point in time.
Currently, it seems too difficult to decouple live components from the parent LiveView because of not being able to initialize itself with relevant data from outside (like querying something based on a param, for instance).
I don’t know about the API, but perhaps something like:
<!-- params or init special assign -->
<live_component module={Module} id={@id} params={foo: foo}/>
<live_component module={Module} id={@id} init={foo: foo}/>
<!-- or passing a tuple to initialize the module -->
<live_component module={{Module, foo: foo}} id={@id} />
1 Like
