dimitarvp

dimitarvp

I agree that having the ID be stored somewhere is the best solution. It gives you future-proofing.

0
Post #11
ruslandoga

ruslandoga

:wave: @derek-zhou

This might be a stupid question since I’m not very familiar with modern LiveView, but why a macro over a function?

Oops, just realized that it’s off-topic. Sorry!

0
Post #12
derek-zhou

derek-zhou

A function will do; maybe I was thinking too much. A macro will expand in compile time so there is less overhead.

0
Post #13
tcoopman

tcoopman

What kind of future proofing does this give you?

This is one of these things where I feel friction with liveview sometimes. I don’t really want to give some things an id, but I have to for liveview. So I’d rather hide it.

To be fair, sometimes you do want an id and then I want to make it visible/explicit.

1
Post #14
dimitarvp

dimitarvp

Mostly in the ability to change how you generate IDs later, plus also being able to parse them and infer anything internal encoded inside of them (like a DB ID).

Granted not the most solid of arguments but I had such needs in the past (not with LV) so I came to appreciate having escape hatches.

0
Post #15
christhekeele

christhekeele

I swear either Phoenix or Liveview has an internal function for making random uniqueish binary refs in its internals that I’ve stolen for similar purposes before, but I’m having trouble finding it.

Update: it was Phoenix.Tracker in :phoenix_pubsub:

  defp random_ref() do
    binary = <<
      System.system_time(:nanosecond)::64,
      :erlang.phash2({node(), self()})::16,
      :erlang.unique_integer()::16
    >>

    Base.url_encode64(binary)
  end

I borrowed it because I was messing with a custom Tracker-compatible system and wanted same-format ids, but also reasoned if it was good enough for Phoenix it was probably fast enough for my other usecases in the application as well, so I used it for some DOM id generation as well.

2
Post #16
slouchpie

slouchpie OP

@christhekeele Thanks for that! It is a bit slower than this :point_up: one though.

iex [3] > :timer.tc fn -> Enum.each(1..1000, fn _ -> random_ref() end) end
{1627, :ok}
1
Post #17
sodapopcan

sodapopcan

So am I just completely wrong about this since no one has acknowledged?

@benwilson512?

0
Post #18
tcoopman

tcoopman

What do you mean with deterministic ids?
I’ve never seen anything like that mentioned.

0
Post #19
cmo

cmo

I believe they mean to keep the IDs the same between renders so you don’t go sending useless data each render. Changing the id is a trick to get it to re-render things (e.g. forms).

I generally use the with_index method for IDs.

0
Post #20