Piping Map.put with access to the piped value

Look up Map.merge/3. Probably something like:

project = Map.merge(project, %{
  budger: total_budget(project.budger_items),
  budget_used: budget_used(project.work_items),
  budget_remaining: project.budget - project.budget_used
}, fn _, existing, _ -> existing end)

Also maybe extract it out as a separate function (get_or_add_budgets ?) in Clients context or something?

Instead of reusing the variable you can take Map.put and wrap it into three separate functions. Each function
will update the struct. Not sure what your struct looks like so I’ll just use %Project{}

def put_budget(%Project{budget_items: budget_items} = project) do
  Map.put(project, :budget, total_budget(budget_items))
end

def put_budget_used(%Project{work_items: work_items} = project) do
  Map.put(project, :budget_used, budget_used(work_items))
end

def put_budget_remaining(%Project{budget: budget, budget_used: budget_used} = project) do
  budget_remaining = budget - budget_used
  Map.put(project, :budget_remaining, budget_remaining)
end

Now you can set up a pipeline for your struct.

def show(conn, %{"id" => id}) do
  project = Clients.get_project!(id)
  |> put_budget()
  |> put_budget_used()
  |> put_budget_remaining()

  changeset = Clients.change_budget_item(%BudgetItem{project_id: project.id})
  render(conn, "show.html", project: project, changeset: changeset)
end

I agree that Map.merge would be good to use here, I just would like to point out that it will override any existing values (unlike Map.put_new). But I would probably restructure the code so that Map.merge would work well.

Thanks everyone, my current approach is now:

  def show(conn, %{"id" => id}) do
    project = Clients.get_project!(id)

    total   = total_budget(project.budget_items)
    used    = budget_used(project.work_items)

    project =
      project
      |> Map.put_new(:budget, total)
      |> Map.put_new(:budget_used, used)
      |> Map.put_new(:budget_remaining, total - used)

    changeset = Clients.change_budget_item(%BudgetItem{})
    render(conn, "show.html", project: project, changeset: changeset)
  end

I still quite like @ericgray s idea of splitting this up into separate functions. I think I would go this way.

I think here the function getting passed to Map.merge/3 makes sure there are no overrides.

Just judging from the code it seems odd to me that you wouldn’t want to override existing values (especially if project is a struct), but the OP says that works for them so I’ll take them at their word.

I also want to +1 the recommendation to put all of this in a function in a context module as opposed to in a controller, which is what appears to be happening.

Ah, good point, you’re correct. I didn’t notice that it was Map.merge/3 being used instead of Map.merge/2.

For what it’s worth, I might do:

# In the Clients module
defp add_budget_data(project) do
  budget  = total_budget(project.budget_items)
  budget_used = budget_used(project.work_items)
  budget_remaining = total - used

  Map.merge(
    project, 
    %{budget: budget, budget_used: budget_used, budget_remaining: budget_remaining},
    fn _, existing, _ -> existing end
  )
end

def get_project_with_budget!(id) do
  id
  |> get_project!()
  |> add_budget_data()
end

# in the controller module
def show(conn, %{"id" => id}) do
  project = Clients.get_project_with_budget!(id)
  changeset = Clients.change_budget_item(%BudgetItem{project_id: project.id})
  render(conn, "show.html", project: project, changeset: changeset)
end

Map.merge/3 is nice succinct solution but I think he wishes to see how to use pipes to transform data. I’m sure he’ll revisit it once he gains more experience. It’s a little harder to understand what Map.merge does as opposed to Map.put

That’s fine. I think there is a practical reason not to create separate functions for each operation - you never want those functions to be called in isolation. You would never call just the function to update the budget and the budget used without also updating the budget remaining, because you would have values that don’t tie (i.e., budget - budget_used might not equal budget_remaining.)

So while normally I would say the degree to which you extract smaller functions from larger functions is ultimately a matter of personal style, in this case it is probably better not to make it possible to use any of these three update functions in isolation.

Good point you’d have to be careful not to call those functions in isolation. I’m not sure exactly what he’s trying to accomplish. Just gave an example of how to pipe it. Great input tho, something he should keep in mind.