Best approach to replace early exits the elixir way

Questions / Help
, ,
1

Hi all

I am still in my early days with Elixir and relatively new to functional languages (did one hobby project in Elm), so most interested in figuring the elixir ways for this or that.

Quite often I am in the situation where I need to have a look at the function input and do an early exit, yet an input validation is something beyond what simple pattern matching or guard could do - a function needs to be called.

For example, in my weather forecast live view there is a handle_event that should only go fetch weather if user has chosen a date already. Otherwise, we just do nothing:

 def handle_event("fetch-weather", _, socket) do
  weatherRow = if (socket.assigns[:target_date] == nil) do
    []
  else
    # actually fill weatherRow with some sensible info
  end
  socket = assign(socket,
      :weatherRow, weatherRow
  )
  {:noreply, socket}
 end

All these argument validation feel to not nice in elixir, but I can’t really think of a good solution.
The best I could think of is about making an original function just extract the data to be validated:

def handle_event("fetch-weather", _, socket) do
  target_date = socket.assigns[:target_date]
  weatherRow = target_date |> handle_fetch_weather_inner
  socket = assign(socket,
       :weatherRow, weatherRow
   )
   {:noreply, socket}
end

defp handle_fetch_weather_inner(nil)
  []
end

defp handle_fetch_weather_inner(nonEmptyTargetDate)
  # Fetch weather using the target date
end

How would you do something like this?
Am I missing some way to pattern match or put guard on the original handle_event?

2

Hi @artem, welcome to the forum. :slight_smile:

I sometimes want a simple return ... call too. I was used to having that in in Swift.

Anyway, here’s a gist I made with a few approaches. Somebody will come up with an even more clever one, I guess. But hopefully, this would be useful for you.

If you have a LiveBook, you can open that file and play with it more.

3

IMO @stefanluptak’s first approach (top-level if with return values in each branch) is pretty standard.

Alternatively, consider interlocking the code so that whatever is sending fetch-weather can’t happen without target_date being in the assigns.

4

Totally different way:

new_blabla = socket.assigns[:blabla]
|> List.wrap
|> do_the_thing_its_always_a_list

Note List.wrap gives [] on nil. It’s a secret power weapon in elixir.

List.wrap(if something = x.y do: process(something))

is also a common pattern in my toolbelt

4 Likes
5

Thank you guys, I didn’t realize I could pattern match on map inside a map as

def handle_event3(
        "fetch-weather",
        _params,
        %{assigns: %{target_date: target_date}} = socket
      )

I guess most proper approach is what @stefanluptak posted as handle_event1, for now I’ll try some more function header matching to learn it more. It probably wouldn’t work if I needed some checks with function calls (e.g. validate_date(target_date)), but for my current needs matching works well.

I figured I can even check for the existence of a key as well as in

 def handle_event("fetch-weather", _, %{assigns: assigns} = socket) when not is_map_key(assigns, :target_date) do
    Logger.info("target_date key is missing")
    {:noreply, socket}
  end

  def handle_event("fetch-weather", _, %{assigns: %{target_date: nil}} = socket) do
    Logger.info("handle_event: target_date is nil")
    {:noreply, socket}
  end

  def handle_event("fetch-weather", _, %{assigns: %{target_date: target_date}} = socket) do
    Logger.info("Going to fetch weather")
    ...
  end
1 Like