I haven’t had a chance to look at the :sets module PRs yet, so I can’t give informed advice. Maybe @Lucassifoni can weigh in, since he worked on the module - curious to hear your thoughts, Lucas! From what I understand, they are just maps in the newest (version 2) implementation.
bartblast
Creator of Hologram
0
tenkiller
I did take a look at Port :sets.union/2 to JS by 4mritGiri · Pull Request #432 · bartblast/hologram · GitHub, which uses Type.map under-the-hood. If that’s the preferred type to use going forward, I can go with that initially and wait for feedback.
0
bartblast
Creator of Hologram
Lucassifoni
Hi Bart,
Indeed they are just maps now. But there are a few “gotchas” re: handling of sets v1/v2 between OTP 24 to 28, you can see my take on that in the currently opened PR for :sets.from_list/{1,2} : https://github.com/bartblast/hologram/pull/416
Not all :sets functions need that shimming though. But ultimately returning a map with empty lists as values is the correct thing to do, and we should emit errors (non replicable in elixir consistency tests) if someone really wants to use :sets v1 (the tuple buckets data structure).
To expand on that, the main sets handling module in Elixir, MapSet, is dubbed MapSet because it used an elixir implementation with maps having lists as values, before switching to :sets when the erlang implementation adopted this simpler data representation, I think as of Elixir 1.15.
Luckily we do not need to support OTP < 24 nor Elixir 1.15 in Hologram 
2
tenkiller
I think I need to wait on @Lucassifoni‘s work to get merged before submitting a PR for :sets.to_list/1. I’ve encountered a certain wrinkle with consistency tests, and I’m not sure what approach to take. Specifically, Erlang sets may contain any data type for its keys, and treats them uniquely.
> :sets.from_list(["a", 3, "3", false], [{:version, 2}])
%{3 => [], false => [], "3" => [], "a" => []}
> :sets.to_list(:sets.from_list(["a", 3, "3", false], [{:version, 2}]))
[3, false, "3", "a"]
But, of course, JavaScript coerces all of its object keys to strings and clobbers '3’ and 3.
> const set = { 3: [], '3': [], false: [], 'a': [] }
{ '3': [], false: [], a: [] }
> Object.keys(set)
[ '3', 'false', 'a' ]
Ouch. 
0
Lucassifoni
Yeah that’s annoying. I need to think about how to circumvent it. Hologram-JS side we should use Type.encodeMapKey. But we need to ensure we can get values out of that, while not using another data representation as valid elixir code could depend on the internal structure of sets.
I have a bit of time this week and would be glad to collaborate on this module
1
bartblast
Creator of Hologram
Just to clarify, we’re not translating Elixir types to JS one-to-one. We’re using boxed types instead. You might want to take a look at the Type.map() function: https://github.com/bartblast/hologram/blob/ad4f2293e7e2da97ca54b6b62c1968e8f4f4679d/assets/js/type.mjs#L399 it’s our ported version of Elixir’s map and should help with the issues you’re seeing.
2
bartblast
Creator of Hologram
@Lucassifoni @tenkiller If something feels clunky, I’m open to adding some new helpers to smooth things out.
0
tenkiller
Ah, Type.encodeMapKey is something I overlooked. That may address some of my issues. Thanks! I’ll make some progress this week and see where it takes me. I’ll keep you in the loop @Lucassifoni.
0
Lucassifoni
I’d be glad if you looked (when you get the time) at the current test helpers I added in the open PR, because on one hand I don’t really like adding helpers, on the other hand I’m not for shimming Elixir modules at test time to make them conform to Hologram’s behaviour (not supporting v1 sets) just for the sake of mirroring js/elixir tests.. that would amount to testing test code IMO since this limitation does not really exist elixir-side.
In retrospect I did not choose the simplest module but it’s the one I truly need to port my app to Hologram x) .
0