Do you have project level patterns with standardized solutions for common problems?

I would use with or || to avoid calling each getter. You might only need to call the first one.

The reason for the case do structure was that no matter the amount of layers there is not going to be any nesting, which would lead to code that is easy to test and maintain in general. Although I hear the argument about not needing to get all the values, in most cases this is very cheap operation. So in order for the with to make sense, it would need to not make any sacrifices in the “complexity/nesting” side of things, so how would you approach the same problem if you used with instead ?

with nil <- get_first_val(),
     nil <- get_second_val() do
  get_third_val()
end

or just:

get_first_val() || get_second_val() || get_third_val()

EDIT: I missed the whatever so if that is important, your case would use with like so:

with nil <- get_third_val(),
     nil <- get_second_val(),
     val <- get_first_val() do
  # do whatever with val
end

About the first part I understand that you still need to define other outcomes for example what happens if you end up getting a result from the “get_second_val” then you still need to match that in the else statement making the hierarchy of the code less apparent (the way I see it) and when it comes to the second approach it’s for sure the most elegant but for me it did not work on the debug phase.

But in general the point of the thread was not to argue about the particular peace of code but rather open a discussion of less common design patterns that might be somewhat domain specific on the context of Phoenix LiveView does this make sense ?

This is pretty much the canonical with use-case as mentioned above, but for times when you already have all of the values a cond can also be used for nil-handling.

cond do
  first_value -> whatever(first_value)
  second_value -> second_value
  true -> default
end

Which is equivalent to this (but easier to read if there are many cases):

(first_value && whatever(first_value)) || second_value || default

i’d use a cond in this context, something like:

cond do
  first = get_first() when not is_nil(first) -> ...
  second = get_second() when not is_nil(second) -> ...
  third = get_third() when not is_nil(third) -> ...
  true -> whatever
end

if you see not is_nil(value) getting repeated a lot, i’d define a guard in this module:

defguard not_nil(value) when not is_nil(value)

Certainly wasn’t trying to argue.

Fully agreed on cond. It seems many people forget about it and I actually know people who actively avoid it (which I don’t fully understand). It’s probably the least used construct but really useful when it is

Otherwise, for specific LiveView stuff, I would need to see more code as there may be cleaner ways of structuring it. For example (and this keeps coming up lately), I very very rarely look at params—I would pass them right to the changeset then check if changes is empty. Otherwise, if a whole key is missing, I would maybe handle these in different handle_event matches. But again, very hard to say without seeing more explicit code.

PS lol at your new avatar, @cevado
EDIT: It may have been a glitch but your avatar has changed again.

I personally like cond too instead of the generic nested case or if/else, but I am not a big fan of assignments in either cond/if, it’s a little bit too much magic, it’s completely confusing for folk that didn’t write elixir and even for newcomers.

The cond will naturally guard against nil (it is falsey). And I don’t think you can use guards in a cond anyway, right?

But I agree with the spirit of your post, and actually I think this is probably better than with:

cond do
  first = get_first() -> first
  second = get_second() -> second
  true -> default
end

But this is all only for nil-handling. If we were dealing with :ok/:error tuples it would be a different story.

I do this constantly. I feel understanding that everything is an expression is required knowledge if you’re going to be writing Elixir. A bit off topic, though.