Fair warning I come from an OOP backround so I might be missing something very obvious here.

Hierarchical Selection of value

Lately I have been trying to go over my elixir project and try to identify potential patterns in the code. One such pattern that I “identified” from my own code when I was working with developing custom components like for example a LiveSearchSelect component etc is the need to get a value through a hierarchical structure like for example get the field value from

1. The form params (for example to get the values of the users latest changes)
   but if this is nil
2. The changeset(For example if the form param are empty due to an update triggered through the changes happened from a javascript trigger interceptor which also triggers re render of the custom component)
   but if this is also nil
3. Maybe some case that exist to save user progress
   but if this is also nil
   “empty string”

So I found this as a let’s say re occurring problem and I came up with a name in order to standardize a solution on this kind of problem for the context of my project at least.

The solution I found to be the most elegant and easy to maintain is the following

{first-degree, second-degee, thrid-degree}  = {get_val, .., ..}
case tuple do 
    {nil, nil, nil } ->
      whatever 
    {nil, nil, third-degree } ->
      third-degree
    {nil, second-degree, _ } ->
      second-degree
    {first-degree, _, _} ->
      third-degree
 end

Do you relate/have any to share?

So I wanted to share this mainly to ask whether other developers can relate ?? and if you have also “project level” patterns with standardized solutions on common problems of either your domain or in general when working with Elixir PhoenixLiveView and relevant technologies.