Small useful macro |> case_continue

1. Piping into case lately became a subject for debates (see don’t pipe into case statements)

2. Macros are awesome! ..mostly for stuff I do on my own
   Especially adding up to the language syntax meant to be commonly used across the project might not be obvious to the team who work with the code.

   Macros should only be used as a last resort. Remember that explicit is better than implicit . Clear code is better than concise code.

   _https://elixir-lang.org/getting-started/meta/macros.html#foreword_

Whenever I notice case of just two branches one of which just returns the input - I think of with

    result =
      ...
      |> Repo.transaction()

    with {:ok, %{goal: goal}} <- result do
      PubSub.broadcast_goal_created(user, goal)
      result
    end

With your macro we can handle more than just one happy path, though.

I don’t find the error -> boilerplate that annoying, personally. I always prefer to unpack results (both successand error) from passing Ecto.Multi to Repo.transaction as close to the transaction as possible, because otherwise operation names become an accidental part of the function’s interface.

I’m also not sure how the above macro accomplishes the task - it seems like a result other than {:ok, %{goal: _}} will fail to match in the generated case statement.

Interesting, is this like a tab vs spaces kinda thing? hehe

I’ll check it out.

Yup, bug found! Too quick to publish (solved above)

Good point. You could still unpack the result in a later case do to give shape to errors.

      |> Repo.transaction()
      |> case_continue do
        {:ok, %{goal: goal}} -> PubSub.broadcast_goal_created(user, goal)
      end
      |> case do
        {:error, :validate_uniqueness, _, _} -> {:error, "not good"}
        result -> result
      end

or even

      |> Repo.transaction()
      |> case_continue do
        {:ok, %{goal: goal}} -> PubSub.broadcast_goal_created(user, goal)
      end
      |> shape_create_goals_response()

To me it feels natural to have a separate step in the pipeline dedicated to call external services. But that’s just me. It’s definitely clearer when dealing with Repo’s update, insert or delete, where Ecto’s interface is usually the function’s interface → {:ok, struct} & {:error, Changeset}.

It depends. Sometimes if “call to external service” fails we would want to rollback the transaction =)) can’t come up with a reasonable example from top of my head why would we took a transaction before external service call, but I have a feeling that I faced that in the past.

Using the then/2 macro introduced in elixir 1.12, you can do:

      |> Repo.transaction()
      |> then(fn 
        {:ok, %{goal: goal}} = result ->
          PubSub.broadcast_goal_created(user, goal)
          result

        error ->
          error
      end)

Where is the debate? This just says: dont do it!

Am i missing something or would one possible solution to define something like Maybe.map that “hides” that case expression away in a generic way (or instead Result.map depending on your context, but that’s not really important)? Maybe and Result modules are common in lots of languages nowadays, so i hope it’s clear what i mean with that. That way you don’t have to define a helper for every situation.

Sorry, should have mentioned. Some discussions can be found here and there.. for example in threads in twitter like this one. Or in some threads in comments in HackerNews [1][2]

There is no case for not piping into case in the links you provided.

Great observation about “maybe” as a name. I actually renamed the macro to maybe_case.

I fail to grasp what you are trying to argue thou. Could you provide some high level code?