slouchpie
Fastest, most lightweight, pseudo-random generator (for HTML IDs)?
A lot of times when I write functional components and live components, I want to make sure I don’t end up with duplicate HTML IDs so I do something like
<div id={"my-component-#{System.unique_integer()}"}
or
<div id={"my-component-#{Ecto.UUID.generate()}"}
or
<div id={"my-component-#{:rand.bytes(10) |> Base.encode16()}"}
I think the last one is best because it is “random” instead of “unique”. Since I am only trying to safeguard against duplicate HTML IDs in the same page, using a “unique” generating function feels excessive.
The question: how do you avoid duplicate HTML IDs and what is a well-suited function to use for doing it?
I would gladly welcome any advice on this.
Marked As Solved
ruslandoga
![]()
# produces something like "-576460752302382141"
iex> :timer.tc fn -> Enum.each(1..1000, fn _ -> System.unique_integer() |> Integer.to_string end) end
{746, :ok}
# produces something like "FE404" <- I like this one
# note: grows larger and larger the longer VM operates, but won't exceed `(NoSchedulers + 1) × (2⁶⁴ - 1)`
iex> :timer.tc fn -> Enum.each(1..1000, fn _ -> System.unique_integer([:positive]) |> Integer.to_string(16) end) end
{787, :ok}
# produces something like "4D37AE7D3E6865A26A64"
iex> :timer.tc fn -> Enum.each(1..1000, fn _ -> :rand.bytes(10) |> Base.encode16() end) end
{1358, :ok}
# produces something like "cd2acfc8-90f2-4c19-9440-5207f49102f2"
iex> :timer.tc fn -> Enum.each(1..1000, fn _ -> Ecto.UUID.generate() end) end
{1722, :ok}
And then there is also Enum.with_index/2 that can be used to give unique ids for a collection of elements.
And I think the latest trend is to actually use fewer ids and instead use aria or data attributes. Summary: You may not need HTML ID's
Also Liked
jhogberg
Why would it be excessive? All that System.unique_integer/0,1 promises is that it will not return the same value twice for the same options, so it’s actually a very cheap function, it essentially just bumps a thread-local counter and returns it.
benlime
Random IDs will also break client-side state. I tried using them as a convenience when using hooks, but as previously mentioned they will re-render on every change and the client side state will be lost as the hooks are identified via the id within LV.
Let’s say you a hook which has a hook with a display toggle functionality. The user interacts with it client-side and causes it to be hidden. If any other state in the same LiveView changes it will cause a re-render of the hook component with a new id. This will cause the hook to reset to it’s default state as it’s essentially a new hook instance.
Using random ids within LV is never a good idea imo. You can still use some module for generating ids, but it would need to always return the same id based on it’s arguments (aka pure function).
tcoopman
Liveview does require idd for a few things, for example when you use hooks.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








