Yep, basically this. Working solo has actually given me the luxury to carve out some time to go back and re-read stuff I wrote a week ago and see how quickly I can understand it. I’ll see!
sodapopcan
Sorc96
Thinking about this again, I realized that at least for me, the complexity comes from the reduce, not the rest. Consider this change to the for version:
names =
for {mockup, mockup_index} <- assoc_with_index.(source, :mockups),
{element, element_index} <- assoc_with_index.(mockup, :elements),
{_transformation, transformation_index} <- assoc_with_index.(element, :transformations) do
"transformation-#{mockup_index}-#{element_index}-#{transformation_index}"
end
socket = Enum.reduce(names, socket, &allow_image_upload(&2, &1))
I would say that the for itself is perfectly fine. The reduce part still takes some time to understand, even when it’s in its simplest form. I would argue this is because reduce is simply the wrong way around, twice, but in any case, the building of the names does not seem to be the problem at all.
1
sodapopcan
I actually quite like that version too! I don’t really mind the for reduce either, though, I think depends on how comfortable with for and its options you are. Some people are all about comprehensions and some people won’t touch them.
I should clarify that I like my original in this case. If I were using assoc_with_index in other parts of the system then I would without question extract it to a helper function. But this case is an anomaly in my app and one that probably won’t change often and probably never be read much. I’m trying to think of someone coming across this and needing to understand it as quickly as possible before moving on. Of course that is very tricky to gauge. It’s almost as if writing good code is hard 
0
Sorc96
Personally, I probably wouldn’t bother looking into assoc_with_index, the usage makes pretty clear what it does. I’m also not saying that I would necessarily rewrite the code like this, I just wanted to show that the reduce was causing the most complexity here, in my opinion.
I guess my issue with the original code is that you need to thread the socket through all the layers in order to use it in the innermost reduce. That complicates it a lot for me, because the creation of the names and modification of the socket are mixed together. So maybe a version with a few flat_maps that generate the values first and then a reduce - basically my for example, but without the for - would be a pretty good solution as well.
2