Surface docs explain it well here:
maz
cmo
also in send_update docs
While a component may always be updated from the parent by updating some parent assigns which will re-render the child, thus invoking update/2 on the child component, send_update/3 is useful for updating a component that entirely manages its own state, as well as messaging between components mounted in the same LiveView.
maz
Error: invalid value for property “vod_ingest”. Expected a :map, got: nil.
I have a stateful surface livecomponent called MediaItemCard that shows a MediaItem. I want to display vod_ingest events while the upload the user just uploaded is being encoded – in the MediaItemCard.
The MediaItem has_one VodIngest and the :vod_ingest field is nil if it is not currently ingesting vod.
In MediaItemCard:
@doc "The media_item vod_ingest data"
prop vod_ingest, :any, default: nil
the parent channel_page.ex:
<MediaItemCard :for={media_item <- @new_media_items} id={"media_item_card-#{media_item.id}"} username={media_item.user.username}
media_item={media_item}
vod_ingest={media_item.vod_ingest}
current_user={@current_user}
media_item_changeset={@media_item_changeset}
playlists={@playlists}
language_identifiers={@language_identifiers}
/>
But I’m not sure why I’m getting the “invalid value for property “vod_ingest” Expected a :map, got: nil.” error on render()
dependencies:
phoenix 1.6.2
phoenix_ecto 4.4.0
phoenix_html 3.1.0
phoenix_live_view 0.16.4
phoenix_view 1.0.0
surface 0.6.1
surface_formatter 0.6.0
background info: my plan to update the card I do Endpoint.broadcast_from(media_item_id) when I get vod_ingest events, which the parent channel_page does handle_info() on. I fetch the MediaItem from the db and then I append the updated MediaItem to the socket.
As an alternative I can use send_update but if the user refreshes the page those get clobbered unless I inject the state directly into the child livecomponent .. right?
derek-zhou
Is surface 0.7.x released? I am having a lot of problem porting my application from 0.6.x. Even simple stuff like:
{#for n <- 1..2}
<span :if={n > 1}>{n}</span>
{/for}
Does not work. It actually works in static rendering, but gives me undefined in live rendering.
I am using surface 0.7.3 and liveview 0.17.7
cmo
@derek-zhou that code works for me and I’m running 0.7.1 and 0.17.7. Maybe clean your _build?
derek-zhou
Will try again later. Also, it seems like Surface is getting a lot stricter. I have some data assigned as :map, but could be nil in some cases. in 0.6.x Surface it works but no longer in 0.7.x. I have to change it to :any. In a dynamic language like Elixir, nil shall be a necessary evil?
derek-zhou
after nuking my _build, it still does not work. I am using elixir 1.12.3, on Erlang/OTP 24 [erts-12.0.4]
What I found is anything dynamic, a component or a html element with a :if pseudo attribute, within a for construct will not render correctly in a liveview.
cmo
I haven’t noticed this and I’m sure I set things to nil. Maybe jump on slack and post your code.
msaraiva
Broadway Core Team
Hi @derek-zhou!
I tested that very same code in many different versions and they all work as expected.
That sounds like a JS thing. Are you using npm? If so, have you tried to nuke your node_modules and run npm install again after updating the libs?
If that doesn’t work, please run liveSocket.enableDebug() in your browser’s console and check if there’s any error/warning message.
derek-zhou
That’s was it. the js side and the elixir side of the Liveview got out of sync; I was basically using 0.16.x js on 0.17.x elixir. I thought about it, but was fooled by the live_dashboard working. It turns out the live_dashboard bundled everything inside. Thanks a lot!
However, I still have the map type check issue:
** (exit) an exception was raised:
** (RuntimeError) invalid value for property "stat". Expected a :map, got: nil.
(surface 0.7.3) lib/surface.ex:246: anonymous fn/6 in Surface.build_assigns/6
I know I can trn the data prop into an :any but it still is annoying. It is a legitimate usage case that some data assigns are not initialized, as long as the templates check for nil, because loading everything takes time. nil is a very convenient marker of uninitialized data.