Maybe: nil protection for nested structs

I have a problem. It’s very common to have nested structs when you deal with Ecto and associations. For example, a Person can have a City, which has a name.

The problem is, city can sometimes be nil. In that case, this code will raise an error. (“nil doesn’t respond to :name”) I want something like Ruby try here.

person.try(:city).try(:name)

Elixir has a built-in thing like this, called get_in:

get_in map, [:nonexistent, :keys]
# => nil

However, it only works with maps, not structs. The documentation says it’s specifically ​_not_​ supposed to work with structs.

So, I have a proposal. We make a module with a functional API like this:

maybe(person, [:city, :name])

And a macro to pretty things up a bit:

maybe(person.city.name)

If any element in the chain returns nil, the expression returns nil.

Here’s my sample implementation:

defmodule Maybe do
  defmacro maybe(ast) do
    [variable|keys] = extract_keys(ast)
​
    quote do
      maybe(var!(unquote(variable)), unquote(keys))
    end
  end
​
  def maybe(nil, _keys), do: nil
  def maybe(val, []), do: val
  def maybe(map, [h|t]) do
    maybe(Map.get(map, h), t)
  end
​
  defp extract_keys(ast, keys \\ [])
  defp extract_keys([], keys), do: keys
  defp extract_keys({{:., _, args}, _, _}, keys) do
    extract_keys(args, keys)
  end
  defp extract_keys([{{:., _, args}, _, _}|t], keys) do
    keys = keys ++ extract_keys(args)
    extract_keys(t, keys)
  end
  defp extract_keys([{:., _, args}|t], keys) do
    keys = keys ++ extract_keys(args)
    extract_keys(t, keys)
  end
  defp extract_keys([key|t], keys) do
    keys = keys ++ [key]
    extract_keys(t, keys)
  end
end

And example usage:

import Maybe

defmodule Person do
  defstruct city: nil
end
	
defmodule City do
  defstruct name: nil
end
	
person = %Person{city: %City{name: "Portland"}}
maybe(person.city.name) # => "Portland"
maybe(person.nonexistent.name) # => nil

Is this a good idea? Should it be named something else? Is there something in the standard library that I missed?

7 Likes

Remember you can use pattern matching:

case person do
  %{city: %{name: name}} -> name
  %{} -> default
end
3 Likes

I’m always confused when matching on %{} (or #{} in erlang)… My intuition does tell me we are matching on an empty map (as we were when matching on []), but in reality it is like anything when is_map(anything).

Is there a certain reason why pattern matching on %{} and [] is treatened differently?

3 Likes

Is there a certain reason why pattern matching on %{} and [] is treatened differently?

They are different structures. Maps were designed to always map on a subset, therefore the empty map ends up matching all maps. Otherwise, imagine how useless pattern matching on maps would be if every time I wanted to take a key from the map, I had to match on all keys. The cases where I would want to do a full matching are rather rare (and can always be achieved with map_size).

12 Likes

This makes absolutely sense, thank you for your answer.

4 Likes

Pattern matching does work, but is quite verbose compared to what @danielberkompas is suggesting.

1 Like

I agree with @jamonholmgren. @danielberkompas 's solution seems like a good way to concisely read data.

Of course, the ruby try() construct can sometimes be considered a code smell, as we’re actually breaking the Law of Demeter here, and a better solution (But often not worth the hassle/extra abstraction) would be to create a proper null-object.
But… I’m getting sidetracked.

I think that Maybe.maybe(some.field.lookup) is a very reasonable way to solve this problem. When using it, a developer explicitly acknowledges that the answer might be nil at any depth of the field lookup.

2 Likes

I see applications for this, definitely. Especially if not only considering structs.

But… doesn’t this actually do what you want, @danielberkompas ?

person |> Map.get(:city, %{}) |> Map.get(:name)

Note the use of the empty map as default. The Map.get/3 works on any struct or map as far as I can tell and returns nil or default if the value is not present. Returning by default the empty map makes it save to string these together, and the last one can simply return nil (the default anyway).

2 Likes

@Oliver, yes, Map.get does do what I want. I actually use it here to provide the functional API for Maybe:

def maybe(nil, _keys), do: nil
def maybe(val, []), do: val
def maybe(map, [h|t]) do
  maybe(Map.get(map, h), t)
end

You can call it like so: maybe(map, [:first, :second, :third]). I think it’s a little more convenient than doing a pipeline.

The maybe macro just converts calls like this: maybe(map.first.second.third) into functional calls for maybe(may, [:first, :second, :third]).

Edit: Since the Maybe module is so small, I decided not to release a hex package for it. If you’re interested, you can find it here: https://github.com/infinitered/phoenix_base/pull/14

5 Likes

Is this still true as of today?

If a structs module implements the Access behaviour, then you can use it with the lense like accessors.

Though a 1:1 mapping to struct keys is often not really what you want for structs. Eg. for a set you might have a couple of struct keys required for the implementation, but each on its own doesn’t have any value. Instead you use Access behaviour to make a lookup in the set and either return nil for inexisting items or the item itself if it is in the set. (This is just an example)

1 Like

What I actually need is a “safe navigation” through Phoenix “models”, exactly the case brought on the very beginning of this thread. A quick test shows the get_in to work so it looks to me that either things changed or there are some gotchas I am not aware of

Hmmm…

For me I can not use get_in on an arbitrary struct…

iex(1)> defmodule S do
...(1)>   defstruct [:a, :b]
...(1)> end
iex(2)> get_in(%S{}, [:a])
** (UndefinedFunctionError) function S.fetch/2 is undefined (S does not implement the Access behaviour)
    S.fetch(%S{a: nil, b: nil}, :a)
    (elixir 1.11.4) lib/access.ex:286: Access.get/3

What have you done?

1 Like

To be frank I don’t know. Now it doesn’t work. So I must have done something differently and can no longer reproduce it :frowning:

UPDATE:
The thing that works for my case is something like:

row = MyApplication.MyContext.MyModel |> MyApplication.Repo.one()
column_value = if is_nil(row), do: nil, else: row.column

Yet I am surely not happy with how it looks. OTOH get_in(row, [:column]) works nicely when row is nil but fails when it is not. get_in(row, [Access.key(:column)]) does the opposite. It works when row is not nil, but fails when it is. And I didn’t come up with a more elegant one-liner to cover both cases. And this doesn’t even touch nested structures/associations.

This makes me wonder… is there really no need for something like an equivalent of Rails’ try in Elixir/Phoenix? Sure I could probably implement something like that somewhere in every project, but that kind of “safe traversal” does look like a very common case to me. At least coming from the Rails (and a few other languages/frameworks) world.

1 Like

I ran into a similar issue where I had lots of structs that were basically wrappers for maps, where I just wanted the compile time guarantee of the structs. I wrote a small using macro that I can add to the top of a struct and then use it with the Access module

defmacro __using__(_) do
    quote do
      @behaviour Access

      defdelegate fetch(term, key), to: Map
      defdelegate get(term, key, default), to: Map
      defdelegate get_and_update(term, key, fun), to: Map
      defdelegate pop(date, key), to: Map
    end
  end

Well, I for one just came into need of this today. Given how clever a language Elixir is, I’m actually surprised there isn’t a feature like this already

Syntax wise I wonder if ? (in place of .) could work.

person?city?name

That reads pretty well to me.

[Update]

I ended doing this, e.g. (person.city || %{name: ""}).name. Which is okay for one level, but still rather ugly for more, e.g. ((person || %{city: nil}).city || %{name: ""}).name.

1 Like