Blog Post: Taking Control of Map Sort Order in Elixir

Blogs & Podcasts Blog Posts
, , , ,
1

OTP 26 was released and the Elixir 1.14.4 builds have been updated! Erlang OTP 26 changed how map keys are sorted, or not sorted actually. Check out this quick tip on how to customize IEx to always sort the map keys with your local development!

11 Likes
Convert a nested struct into a nested map
2

This is great, and I love that you shared your personal ~/.iex.exs, definitely gives me some ideas!

I’ll add that I’m also a big fan of defaulting to always printing charlists as lists of numbers:

IEx.configure(
  inspect: [
    charlists: :as_lists
  ]
)

This prevents the common confusion of wondering why the list of integers you were operating on suddenly renders as text.

6 Likes
3

Great post, is there a way to do this for tests too?

Currently I am doing something like

if :erlang.system_info(:otp_release) >= '26' do
  ...
else
 ...
end

But that’s ugly.

1 Like
4

Yes, good question.

I have unit tests failing on OPT 26 too. The failure is indirect, as I don’t do direct assertions on Map, but on json response.

Is there a way to deal with this, out of IEx.configure?

5

Did anyone find a solution for tests?

6

I think it depends on the issues exhibited by your tests. In terms of testing for error messages that are inspecting maps, note that the kernel inspect has the same sort_maps option as the IO.inspect. So you can do

Logger.error("Error: #{inspect(error, custom_options: [sort_maps: true])}")

However that is a bit of a PIA to do across the whole codebase. Does anyone know is it possible to set sort_maps as a default for inspect?

7

While this isn’t the answer you’re looking for, I find it’s best for tests to not count on the order of map. You can assert a match, for instance, where the fields in the map you care about for the test match the output.

These types of tests tend to hold up better as returned maps evolve with more data being added but aren’t relevant for the test. It avoids causing unrelated failures.

3 Likes
8

Yes we ended up at that conclusion ourselves. In the end there weren’t too many places where we had inspected a whole map into an error message. Currently fighting with Jason encoded AWS Publish data which again was tested against the whole expected message and which Jason is now randomly changing the order of. Nothing is ever simple!

1 Like