which actually renders computer1_id, computer2_id etc. as a string, but does not run the command to get the actual id from the @computer1 assigned to the socket. Is what I want possible?
You shouldn’t dynamically create atoms - that’s not what they’re for. If you anticipate NEEDING interpolation (e.g. you have 1000 computers), then each one should not be given its own atom key in the assigns, but rather stored with string (or integer) keys in a map, like:
Then you can access the ids from the template like:
for x <- 0..5 do
<%= @computer_ids["computer#{x}_id"] %>
end
But if you don’t have so many IDs, and you would like to keep each one as a separate atom key in the assigns, then you should create a helper function in your view which explicitly handles each case, for example:
def computer_id(x, socket) do
case x do
0 -> socket.assigns.computer0_id
1 -> socket.assigns.computer1_id
2 -> socket.assigns.computer2_id
3 -> socket.assigns.computer3_id
4 -> socket.assigns.computer4_id
5 -> socket.assigns.computer5_id
end
end
and then in the template
for x <- 0..5 do
<%= computer_id(x, @socket) %>
end
It’s usually a bad idea to create atoms dynamically, yes. But in this case I’d argue it’s fine, considering they’re not generated from random user input, but rather a bounded well-defined range.
Could also use String.to_existing_atom to do it without risking the usual problems with dynamically generated atoms.
It’s all still sort of weird though, it’d be much more idiomatic to have the key of the computers map just be the id itself, I don’t see how it helps to have it surrounded by extra atom or string content:
%{
1 => %Computer{},
2 => %computer{}, etc
}
Then you can simply look up the computers by id. BUT even this is sort of weird, it would make more sense for the @computers assign to be an ordinary list where the items are simply sorted already into the desired order, and then it can be iterated through as for computer <- @computers do and we skip all of the extra lookups.