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.
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.
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.
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.
I’ve only used Javascript a little. The changes introduced with ES6 makes the language more pleasant to use IMHO. Typescript is better again. Worth checking out if you do need to use Javascript at some point.
Many languages have a JavaScript source-to-source compiler (transpiler) for exactly this reason - javascript syntax. Ruby has Opal (opalrb.com) and there are others. There is a guy doing this for Elixir (ElixirScript)
I don’t know how well it works, but I hope he succeeds and the project grows.
Btw, as you are a noob like me, I’m curious what book(s) and other resources are your favorites for learning Elixir? happy coding! -Brad-