A few weeks ago, I posted an article about my favorite pattern without a name. Surprisingly, this article got quite a bit of feedback, both good and bad.
People were quick to point out that this pattern did indeed have a name. It’s a fluent interface! It’s an interceptor, a la Clojure! It’s a lense! No wait, it’s just plain-old functional composition!
Some people pointed out that, regardless of what its called, it’s an awful pattern.
While all most of these comments were relevant and useful, I found one of the discussions around this article especially interesting from a practical point of view; my friend Charles Watson introduced me to the beauty of Elixir’s with macro!
Criticisms
The original example we started with in my previous article looked something like this:
user = get_user(sms.from)
response = get_response(sms.message)
send_response(user, response)
After constructing an all-encompassing state object and chaining it through our three methods, we were left with this:
%{sms: sms, user: nil, response: nil}
|> get_user
|> get_response
|> send_response
The main criticism of this approach largely boils down to the fact that we’re allowing our functions to know too much about the architecture of our final solution.
By passing our entire state “God object” into each function, we’re obfuscating the actual dependencies of the function. This makes it difficult to determine what the function actually does, and what it needs to operate.
From a practical standpoint, this chaining also presents problems with error handling.
Our original solution assumed that all of our functions succeeded. However, what happens if any of the functions in our chain fail? Can we even tell how they would fail in our example? Would they return an :error tuple? Would they throw an exception?
It’s hard to tell from reading the code, and even worse, both failure modes would lead to a less-than-ideal debugging situations.
Thankfully, we can refactor this solution to use the with macro and address both of these criticisms.
Using the With Macro
With Elixir’s with macro, we could have refactored our original example to look like this:
with
user <- get_user(sms.from)
response <- get_response(sms.message)
do
send_response(user, response)
end
So what’s the big deal? Arguably, this is much less clean that both our previous refactor and our original implementation!
While using the with macro does cost a few extra characters, it doesn’t come without its benefits.
In our original example, I happily glossed over any errors that might have occurred during our SMS sending process.
Imagine if get_response encountered an error. What does it return? Judging by the fact that a happy path call returns a response object, it’s easy to assume that an error would result in an exception. What if we wanted to gracefully handle that error, rather than having our process blow up?
Let’s pretend that we’ve refactored get_user, get_response, and send_response to return either an {:ok, result} tuple if everything went well, or an {:error, error} tuple in the case of an error.
We could then refactor our with-powered function pipeline to gracefully handle these errors:
with
{:ok, user} <- get_user(sms.from)
{:ok, response} <- get_response(sms.message)
{:ok, sent} <- send_response(user, response)
do
{:ok, sent}
else
{:error, :no_response} -> send_response(user, "I'm not sure what to say...")
error -> error
end
Our with assignments happen in order. First, we call get_user and try to pattern match it against {:ok, user}. If that fails, we fall into the else block where we try to pattern match against our known error patterns.
If get_user fails with an {:error, :user_not_found} error, for example, that error will match the error -> error case in our else block and will be returned by our with expression.
Even more interestingly, if get_response fails with a {:error, :no_response} error, we’ll match against that error tuple in our else block and send an error response back to the user.
Using with, we’re able to short circuit our function pipeline as soon as anything unexpected happens, while still being able to gracefully handle errors.
Another added benefit of using with over the pattern I described in my previous post is that it doesn’t artificially inflate the surface area of the functions we’re calling.
Each function is passed only the exact arguments it needs. This reduction of arguments creates a much more understandable, testable, and maintainable solution.
On top of that, by specifying arguments more explicitly, a natural ordering falls out of our function chain.
Final Thoughts
While this is a fairly contrived example, with can be used to gracefully express complicated functional pipelines. I’ll definitely be using the with macro in my future adventures with Elixir.
I’d like to thank my friend Charles Watson for pointing out the with macro to me and showing me just how awesome it can be.
If you’re interested in this type of thing and want to dive deeper into the world of functional composition, I highly recommend you check out this response to my previous article, left by Drew Tipson. He outlines many interesting topics which are all fantastic diving boards into worlds of amazing topics.
Happy composing!