I thought I would make one of these “improve this code” posts even though this problem isn’t really at that interesting (but here we are). I don’t hate my solution but I feel like it could perhaps be a little more readable. I’m not sure. It’s not bad, but maybe it could be better? Maybe there is an existing way to do this? I am aware of breadcrumble_ex but it’s too explicit for my use-case. I’d also like a better name, though not putting that on you all.
So this function takes a URI path (eg. /path/to/some/place) and turns it into a list of tuples suitable for a presenter to blindly turn it into breadcrumbs. Here it is:
defmodule ExampleModule do
@doc """
Takes a path and return a list of tuples in the form of:
[{"segment", "/path/to/segment"}]
## Example:
iex> ExampleModule.segment_path("/path/to/segment")
iex> [{"path", "/path"}, {"to", "/path/to"}, {"segement", "/path/to/segment"}]
This is useful for making breadcrumbs.
"""
def segment_path(path) when is_binary(path) do
path
|> String.split("/")
|> Enum.reverse()
|> do_segment_path([])
end
defp do_segment_path([""], acc), do: acc
defp do_segment_path([segment | rest] = path, acc) do
path =
path
|> Enum.reverse()
|> Enum.join("/")
acc = [{segment, path} | acc]
do_segment_path(rest, acc)
end
end
That’s it!
Not too exciting, I know. I mostly like this little problem since this is one of those cases where building a list from the end is actually what we want to do. Of course, this just means we reverse it at the beginning as opposed to the end, and then again each iteration to put each segment in its correct form. That’s the big thing I think I would find confusing about this coming back to it later with no context.
Code-golf answers are welcome, but I’m ultimately looking for readability improvements.
Enum.scan.3 is actually what I was looking for, but the name didn’t poke out to me. Looks like I need to just do another read-through of the entire Enum module as it’s been quite a while. Stream.iterate/2 is super interesting and was wholly unaware of it.
@msimonborg I like your points but interestingly or not, I always do my best to find an alternative whenever I find myself needing reduce. It’s not that I think it should never be used, and it certainly is sometimes, but I feel it hurts code “scannability”. Since reduce is the most generalized enumerator you can get, just reading its name alone tells an incredibly generalized story about what is about to happen. This forces me to read through a bit of the implementation, even if I don’t care about it, thus hurting scannability. So I always look for an alternative in Enum that is going that is more tailored to what I want to accomplish. Of course, in this instance, not only did I completely miss scan/3, I chose recursion which is definitely not more “scannable”. While I don’t avoid reduce at all costs, I was definitely trying to do so and took it a little too far this time.
That said, I would say that the scan/3 solution is my favourite here. While I somewhat agree that it is better to use functions that more people are familiar with, I feel like once you come across a function a couple of times and look it up it becomes pretty ingrained. Now that I know about scan, just seeing the name itself will give a lot of information about what’s about to happen, and I prefer optimizing for that.
This was for one of my several abandon projects so it never grew. At one point I had my personal site in LiveView until I decide to switch over to Hugo. This is what I landed on but it didn’t have time to grow. It’s based off of @al2o3cr’s first suggestion suggested along with a component. I just build up segments are two-tuples with {segment, path}.
As this is old code I’m not going to look over it to see if I’m embarrassed by it or not as I might not post it
# In a Utils module
@doc """
Taks a path and return a list of tuples in the form of:
{"segment", "/path/to/segment"}
## Example:
iex> segment_path("/path/to/segment")
iex> [{"path", "/path"}, {"to", "/path/to"}, {"segement", "/path/to/segment"}]
This is useful for making breadcrumbs.
"""
def segment_path(path) when is_binary(path) do
path
|> String.split("/", trim: true)
|> Enum.scan([""], &[&1 | &2])
|> Enum.map(&{hd(&1), Enum.join(Enum.reverse(&1), "/")})
end
# In a components module
def breadcrumbs(assigns) do
admin_path = String.replace(assigns.current_path, ~r/\A\/admin/, "")
breadcrumbs = segment_path(admin_path)
breadcrumbs = [{"dashboard", ""} | breadcrumbs]
last = List.last(breadcrumbs)
assigns = assign(assigns, :breadcrumbs, breadcrumbs)
~H"""
<div class="cursor-default">
<%= for {name, path} <- @breadcrumbs do %>
<span class="after:content-['/'] after:text-gray-500 last:after:content-['']">
<%= if {name, path} == last do %>
<%= String.capitalize(name) %>
<% else %>
<.redirect to={"/admin#{path}"}><%= String.capitalize(name) %></.redirect>
<% end %>
</span>
<% end %>
</div>
"""
end
Ok, I did look it over. It’s a little more complex than it needs to be for a show-and-tell but the admin specific stuff is because I was only using them in the admin section. segment_path/1 is the main thing. This was pre-verified routes and one of the reasons I was excited about them.
EDITED: Man, I really didn’t re-read this thread before posting. Sorry for the repeated context.
I’d recommend keeping your original code to segment the path - the new code might be more efficient, but I’d care more about readability than efficiency in code that deals with a string and resulting list of maybe 5 items.
For utility functions like these that do one very simple tiny thing that will very likely never change (and I wish were just in a library), I prefer them to be terse. When they take up a lot of lines it psychologically makes me think they are doing something really important when skimming through code. That’s just me and my personal projects, though. If I wrote that as part of a team and someone wanted me to change it, I wouldn’t protest.
If I wrote this today (this was 9 months ago… I just got pinged on this relatively old thread) I would probably expand the shorthand anonymous functions.
The do_ for private functions that recurse is a very common Elixir idiom which is why I do it. I didn’t like it at first but I really like it now as it acts as general visual “glue” for all recursive functions.
do_ for recursive functions is something the core team has explicitly moved away from, on the base that it’s just lazy naming, and leads to move your core logic into a private function - which is like stuffing your mess into a closet, close the door and call the room “cleaned up”
My opinion on this: if you can’t come up with a name for your recursive function other than do_public_fun, then your logic should probably live in the public function.
In complex cases for sure—I did a little parser thing once and didn’t use do_ at all, but I honestly don’t write a lot of recursive functions. I mostly do simple cases and (and I’m entering into mega bikeshed territory here) I hate when things have names for the sake of having names… if that makes sense? Like when I see _other -> true in a catch-all or the like. I name my _ vars 99% of the time but case like that I’m like, “Duh, I know it’s ‘other’!”
I dunno, I’m procrastinating on a project right now
Hopefully this is at least par for the course . @Ninigi I’m interested in what you’d use instead of do_ here.
defmodule Example do
def segment_path(path) do
path |> String.split("/", trim: true) |> do_segment_path("")
end
defp do_segment_path([], _path), do: []
defp do_segment_path([current | rest], path) do
new_path = "#{path}/#{current}"
[{current, new_path} | do_segment_path(rest, new_path)]
end
end
this is inefficient, but easy to follow and short. I opt for easy here because this will never be time critical.
“Fast-readability” is also a kind of fast code.
Late to the party here, but I’d use the Path helpers:
def segment_path(path) when is_binary(path) do
do_segment_path(path)
|> Enum.reverse()
end
defp do_segment_path("/"), do: []
defp do_segment_path(path) do
[ { Path.basename(path), path } | do_segment_path(Path.dirname(path)) ]
end