One of the stupidest most bike-sheddy things I absolutely loved about Elm was the commas prepended to new lines. Lists like:
[ :apple
, :banana
, :cherry
]
so that the elements are all left aligned and you never worry about trailing commas.
stevensonmt
sodapopcan
Is that really how Elm works? Is it not this?:
[ :apple
, :banana
, :cherry
]
If so, that just translates the trailing comma problem to the preceeding comma problem. I’ll give you that it is less common to append than to prepend but it still doesn’t help the diff situation. Although, if it allows double commas like that, that is a whole other thing!
1
Eiji
Is it really about language or just a code formatting preference? I believe you can achieve that with a custom formatter plugin. That’s said I don’t really like this idea. If we would really go for a custom formatting plugin then I would simply allow trailing comma even on the last element (when the map or list has more than one line.
0
stevensonmt
haha, yeah that was my bad. It’s not double commas. But it’s also not an issue with the preceding comma because you’d have it on a whole new line and visually find it immediately if the formatter didn’t already handle it for you (which it does).
0
sodapopcan
@Eiji I was specifically talking about the doubled up commas @stevensonmt had erroneously included (and has now fixed).
I have no problem with this style and actually like it. My main point is that for me the real advantage of trailing commas is for cleaner diffs when appending to a list, this style gives you the same problem when prepending.
Otherwise, they are super convenient but I personally don’t care about too much about not having them. I would absolutely use them if the formatter allowed it but actually prefer it visually without them, so I have a love/hate relationship with the formatter there.
One thing that absolutely does drive me nuts and I can never get used to is this style of tuple return for LiveViews:
{:noreply,
socket
|> assign(:foo, "foo")
|> assign(:bar, "bar")}
My team at work uses this and multiple times per week I go to append a new assign and add it after the }. It’s an easy fix but gives me a visceral reaction every time. I know it’s prevalent and have seen people preach it as GoodStyle, but I do not (and will not) understand the aversion to assigning variables.
EDIT: I wrote “arrows” instead of “commas” (WTH? 
)
6
Eiji
You can write a macro or a function to solve this depending on what you prefer.
# if block returns socket wrap it in noreply
handle_event :some_message, _params, socket do
socket
# …
|> reply(some: :data)
end
# if returns a tuple leave it as-is
handle_event :other_message, _params, socket do
socket
# …
end
# otherwise warn/raise error
handle_event :bugged, _params, socket do
:oops
end
defp reply(socket, data) do
{:reply, data, socket}
end
It would be awesome if by default Phoenix would use :noreply and allow to reply with assign/2 or reply/2 function instead of wrapping it in the tuple.
assign(socket, :phx_reply, some: :data)
# or
reply(socket, some: :data)
1
sodapopcan
Ha, I tried those out for a while and didn’t like it. I much prefer re-binding a socket variable and doing {:noreply, socket} (though I will do {:noreply, assign(socket, :foo, :bar)} if there is only one assign). It’s verbose, but it’s explicit and readable. I have snippets that makes writing them painless, though I should really be using AI by this point—I’m just old and slow.
5
eahanson
For those that like this style, Moar.Sugar implements a bunch of these. You can add the library to your project or just copy the code.
1
stevensonmt
Very cool library. I do think the function names are not consistent with normal Elixir conventions. Like noreply/1 and noreply!/1 are not analogous to Map.fetch and Map.fetch!. The noreply/noreply! pair do inverse things to their arguments (wrap vs unwrap) whereas fetch/fetch! do the same things and differ in how they handle errors. Put another way, it’s the argument type that differs rather than the handling of the arguments. The specs from the Map module docs for fetch and fetch!:
@spec fetch(map(), key()) :: {:ok, value()} | :error
@spec fetch!(map(), key()) :: value()
versus for Moar.Sugar.noreply and Moar.Sugar.noreply!
@spec noreply(term()) :: {:noreply, term()}
@spec noreply!({:noreply, term()}) :: term()
Maybe this doesn’t matter to anyone else, but I would find it less confusing to have unwrap in the name of functions that unwrap tuples, with an unwrap! variant that raises an exception rather than returning an error if there is one. I do love little convenience libraries like this though.
2