Thanks for this.
I assume the code below is generally protected from an “atom spam” attack , correct?
def handle_event("sort_by_string", %{"field" => field}, socket) do
atomParam = String.to_existing_atom(field)
if socket.assigns[:sort_by_name_ascending] == false do
sorted_testbeds = Enum.sort_by(socket.assigns.testbeds, fn item -> Map.get(item, atomParam) end) #hardware is hard coded as an atom
{:noreply, assign(socket, testbeds: sorted_testbeds, sort_by_name_ascending: true)}
else
sorted_testbeds = Enum.sort_by(socket.assigns.testbeds, fn item -> Map.get(item, atomParam) end) |> Enum.reverse() #hardware is hard coded as an atom
dbg(sorted_testbeds)
{:noreply, assign(socket, testbeds: sorted_testbeds, sort_by_name_ascending: false)}
end
end
I am a bit confused how I would use that case statement but assuming String.to_existing_atom(field) works just as well, I prefer it as it’s more explicit.
I did some quick searching and the googles returned this blurb:
In Erlang and Elixir, you should avoid using atoms when: you are dynamically generating a large number of unique atoms based on user input or external data, as this can potentially lead to “atom exhaustion” where the system runs out of memory due to the limited number of possible atoms that can exist within a single Erlang VM instance; in such scenarios, consider using strings and converting them to atoms only when necessary using
String.to_existing_atom/1to ensure only pre-defined atoms are used.
