I didn’t want to bring this up while you were still trying to get things working, but now that you have: are any of the fields that you are sorting on structs? If so, I would recommend looking at: Enum — Elixir v1.20.2
jswanner
wktdev
I’ll set your reply as the answer but this is extremely confusing to me. This doesn’t feel like conventional web development. The only reason I had any use for handle_info was to set up the pub sub configuration where I kluged together tutorial content until it worked and then retroactively wrote my own write up to give me at least some kind of understanding as to what is happening. I flat out don’t understand the thought process behind most Elixer/Phoenix development beyond what I can reference from the JS world.
I keep wanting to grab some data and just stick it on another piece of data but then I need to go through all these hidden orthogonal passage ways to do what I want to do.
I understand socket.assigns as a tool to store state on but never thought I would need to use “handle_info” to make this work.
0
jswanner
With many of the standard library server behaviours, like GenServer, handle_info/2 is the callback used for handling generic messages sent to the process, and LiveView is built upon GenServer. While the Phoenix.LiveView behaviour defines additional callbacks (handle_event/3, handle_params/3, mount/3, etc.), it also includes some of the GenServer behaviour callbacks as well (handle_call/3, terminate/2, etc.).
So, if anything sends your LiveView process a generic message then the way that you can respond to that message is by defining handle_info/2; what’s sending the LiveView process that message could be itself (send(self(), :foo)), or some other process.
I don’t know what you are using for pub sub, I’m assuming Phoenix.PubSub but I’m not certain. With Phoenix.PubSub, the publishing side broadcasts a message Phoenix.PubSub.broadcast(MyPubSub, "foo", :message), any process can subscribe to that topic Phoenix.PubSub.subscribe(MyPubSub, "foo"). In this example, if a process was subscribed to that topic before the broadcast then in its mailbox will be a message of :message, the way for a Phoenix.LiveView process to handle that message would be to implement something like: def handle_info(:message, socket), do: {:noreply, socket}.
I’m always shocked by how little code I need to write in order to have my LiveViews live update in response to data changing elsewhere in the application.
Assuming I have business/context/domain code (whatever you want to call it) like this:
def update_testbed(testbed, params) do
testbed
|> change_testbed(params)
|> Repo.update()
end
And a LiveView along the lines of:
def mount(%{"id" => id}, _, socket) do
{:ok, assign(socket, :testbed, Testbeds.get_testbed!(id))}
end
Then in order to have the LiveView update itself whenever that testbed is changed, this is the gist of what I’d change:
def update_testbed(testbed, params) do
testbed
|> change_testbed(params)
|> Repo.update()
+ |> case do
+ {:ok, testbed} ->
+ Phoenix.PubSub.broadcast(MyPubSub, "testbeds:#{testbed.id}", {:testbed_updated, testbed})
+ {:ok, testbed}
+
+ other ->
+ other
+ end
end
def mount(%{"id" => id}, _, socket) do
+ if connected?(socket), do: Phoenix.PubSub.subscribe(MyPubSub, "testbeds:#{id}")
{:ok, assign(socket, :testbed, Testbeds.get_testbed!(id))}
end
+def handle_info({:testbed_updated, testbed}, socket) do
+ {:noreply, assign(socket, :testbed, testbed)}
+end
I think it’s pretty incredible to be able to do that with ~12 lines of code, I would be interested in knowing about any framework/language that makes such a thing easier.
2
wktdev
When a liveview app starts how is its state established (or invoked ) relative to other parts of the app? I’m online looking for answers but I might as well ask while I’m here.
I am asking because the code you helped me with does not start up with a default order. It only establishes order after the sort_field: property is manually updated by a user event. Setting :name to it, it will not be sorted on first render
sort_field: :name,
0
jswanner
def mount(_params, _session, socket) do
TestBeds.subscribe()
Alerts.subscribe()
sort_direction = :asc
sort_field = :name
testbeds =
TestBeds.list_testbeds()
|> Enum.sort_by(fn item -> Map.get(item, sort_field) end, sort_direction)
{:ok,
assign(socket,
testbeds: testbeds,
sort_direction: sort_direction,
sort_field: sort_field,
alerts: Alerts.list_alerts(),
developer: "None",
name_warning: ""
)}
end
1
garrison
If you’re going to update the list in several places, you can define a function to avoid repeating yourself.
defp update_testbeds(socket) do
%{sort_field: sort_field, sort_direction: sort_direction} = socket.assigns
testbeds =
TestBeds.list_testbeds()
|> Enum.sort_by(&Map.get(&1, sort_field), sort_direction)
assign(socket, :testbeds, testbeds)
end
1
wktdev
garrison
The whole LiveView is a state machine on the socket. Callbacks (mount, handle_event, handle_info) take in the socket and return an updated socket.
1
jswanner
The callbacks that are run at the start of a LiveView are, in order: mount/3, handle_params/3, and render/1. And, that sequence is executed twice: first for the static (“dead”) render, and then for the “connected” render (once the websocket is connected).
The rest of the callbacks are executed in response to other things happening: handle_event/3 for an event sent from the client, handle_params/3 because of something like push_patch/2, handle_info/2 for a generic message being sent to the process, and there are others… If the socket.assigns are updated in any of these callbacks then render/1 will be run again.
2
wktdev
With many of the standard library server behaviours, like GenServer,
handle_info/2is the callback used for handling generic messages sent to the process, and LiveView is built upon GenServer. While thePhoenix.LiveViewbehaviour defines additional callbacks (handle_event/3,handle_params/3,mount/3, etc.), it also includes some of theGenServerbehaviour callbacks as well (handle_call/3,terminate/2, etc.).
I am not an Erlang developer so my point of reference is building web apps. Most of everything you said is foreign to the tactile process of web app development.
Phoenix provides a lot of goodies to help you get started quickly and I find myself tolerating it because of this. I am confident that if I was cobbling together this little search feature in react I would have had it done quickly. I’ve been working on this off and on for a week and the thought process still doesn’t make complete sense to me. I’m not productive and I feel stupid.
Regarding your Pub Sub comments.
Wiring up Socket IO to a JS app just seems more clear and the getting started tutorial is easy to read.
If you do a search for socket.io they have a clear tutorial here:
Tutorial - Introduction | Socket.IO
If you do a search for pub sub in phoenix you get this:
As a web app developer, this Phoenix “instruction” doesn’t offer any tactile explanation to get me up and running. It feels like an Erlang developer wrote it for other Erlang developers.
I look at Phoenix and Elixir as a hobby. It is probably the superior most wonderful tool for all things web, but it really doesn’t matter if you need to machete through a jungle of jargon and weird orthogonal network concepts to do simple web things.
0