You can use a function and use pattern matching/guards to do this task:

def convert_id(%{id: id} = data) when is_binary(id), do: %{data | id: String.to_integer(id)}
def convert_id(%{id: id} = data) when is_integer(id), do: data

Or you can use Map.update!/3 with an anonymous function:

map = Map.update!(map, :id, fn
  id when is_binary(id) -> String.to_integer(id)
  id when is_integer(id) -> id
end)

Both approaches are untested and build in a way that they will crash when id is not parsable into an integer or already is an integer. Also both will crash when there is no key :id in the map.

But why does this happen at all? A much better approach were to build the system in a way that the id is always an integer.

if (map.id |> is_binary), do: map |> Map.replace!(:id,100)

This will not change map.

To make it actually change the value of map you need to assign the result like this:

map = if (map.id |> is_binary), do: map |> Map.replace!(:id,100)

But we do not have an else branch, so what happens when map.id is not binary? We’ll get nil into map, thats not quite the expectation. So we need to add , else: map to make that work as well.

Also I do not think, that piping gives anything here, in fact after adding the else branch, we get another set of parens that feels placed wrong. Since both involved pipes are single “staged” its more readable (in my opinion) to just apply the function.

Yeah, I’m a noob also and just punched that into iex. OK, how’s this?

map =  case (map.id |> is_binary) do
               true -> Map.replace!(map,:id,100)
               false -> map
            end

Yes, that sounds like the better approach. In this case, the id is an integer inside the system but provided as a string by a GraphQL query. The GraphQL query data is transformed into a struct, which is then used internally in the system. I’ve tried to write single to_struct(map = %{}) function that would take different shaped maps into account, rather than have the various bits of map transformation code spread over the place. Perhaps that needs to be rethought. Anyway, that’s just background.

Thanks for the guard example. That will be useful!

Well, I’m not sure if this is better or worse than the ops original code, but at least I can tell you, that I dislike cases that match only on true and false and nothing else, you can use an if-expression there as well, which is often more readable.

Said that, I try to avoid ifs at all and try to use functions instead, because I can re-use the functions much easier and piping through function calls reads so much nicer than pipiing into and out of cond/case/if.

Perhaps you should repair your GraphQL schema then, such that the query gives you an integer? Or convert it at the earliest place you can imagine where you know for sure its a string. Usually that is where you receive and parse the query.

I’m still trying to get used to all the different ways of using pattern matching. That way of updating a map looks odd n not very intuitive (to those new to Elixir). Using the pipe to split a list into head|tail I got that right away, but not this…

%{data | id: 100}

To be honest that has been one of the difficult things to learn in Elixir syntax. All the different uses of the pipe and arrows pointing in different directions for different constructs.

That sounds better again! I’ll do some googling to figure out how to do that. (I’m a GraphQL noob too!)

Elm has similar syntax and so does Javascript with the spread syntax. But yeah, I’m still trying to get used to all the various pattern matching things as well. It’s quite different to my every day language, Delphi.