I cannot figure it out which solution is better, the one presented or the one José Valim created? Seems they are doing slightly different things.
mihai-ciupina
i-n-g-m-a-r
This decode as stuff is pretty cool.
So why is it not part of Phoenix? (or am I missing something)
This won’t work:
defmodule Stuff do
defstruct foo: nil, bar: nil
end
def handle_in("send_stuff", %Stuff{} = my_stuff, socket), do: something_with(my_stuff)
The incoming json is already decoded, so I would have to do something like:
def handle_in("send_stuff", %{} = my_stuff, socket) do
my_stuff
|> Poison.encode
|> (fn ({:ok, json}) -> Poison.decode(json, as: %Stuff{}) end).()
|> something_with
end
My solution is to not use structs, which I don’t like, I would love to use structs.
%Stuff{} = my_stuff is a lot more concise than %{"foo" => foo, "bar" => bar}
In case of many parameters, the function definitions become unreadable and ugly,
which is not an enjoyable kind of pattern matching.
Am I missing something?
0
i-n-g-m-a-r
The decode as stuff will not compile in conjunction with @enforce_keys.
Probably this is related to the absence of the %Stuff{} = my_stuff feature.
0
peerreynders
At the risk of stating the obvious
defmodule Stuff do
defstruct foo: nil, bar: nil
def from_map(%{"foo" => foo, "bar" => bar}),
do: %Stuff{foo: foo, bar: bar}
# alternatively - return some error
def from_map(m),
do: m
#...
end
# ...
def handle_in("send_stuff", stuff, socket) do
with %Stuff{} = my_stuff <- Stuff.from_map(stuff) do
something_with(my_stuff)
else
# do something else with "stuff" argument ...
end
end
# ... or
def handle_in("send_stuff", stuff, socket) do
case Stuff.from_map(stuff) do
%Stuff{} = my_stuff ->
something_with(my_stuff)
# other options ...
_ ->
# ...
end
end
1
i-n-g-m-a-r
Tnx for your suggestions, much appreciated.
I’m trying to avoid boilerplate code in struct definitions and
if/else/with/case statements in functions (I prefer pattern matching).
I am thinking about something like this, using a helper function:
def to_struct(%{} = params, kind) do
params
|> Poison.encode
|> (fn {:ok, json} -> json end).()
|> Poison.decode(%{as: kind, keys: :atoms!})
|> (fn {:ok, decoded} -> decoded end).()
end
def handle_in("send_stuff", %{} = m, socket) do
m |> to_struct(%Stuff{}) |> something_with
end
defp something_with(%Stuff{} = stuff), do: ...
Or maybe I should just skip decoding/encoding and do something like this:
// javascript
let data = { "json": JSON.stringify(actual_stuff) };
// push...
// elixir
def handle_in("send_stuff", %{"json" => json}, socket) do
json |> Poison.decode(%{as: %Stuff{}, keys: :atoms!}) |> something_with
end
Any thoughts?
0
amnu3387
Not sure you want to, but you could also use an ecto embedded schema definition, which would allow you to just cast the json into a “structure” (including type conversion)
1
i-n-g-m-a-r
Surely ecto provides some very nice functionality that could be used in this context.
Also I would never persist anything without using ecto, embedded or otherwise.
I was thinking about defining embedded modules with structs inside a module that uses Phoenix.Channel.
The structs would tell me about the kind of stuff coming in and the function definitions would be short.
So it’s more about clarity than anything else.
0
peerreynders
I must be missing something - why does Poison have get involved in to_struct? I suspect it’s because you really want to use the Poison.Decode.transform/2 functionality.
Given that the transform process relies on empty structs (possibly nested) I’d be tempted to just code the necessary boilerplate conversions without Poison - that code can go into a separate module from the struct definition. If there is an opportunity to eliminate the boilerplate in the future, great - otherwise 
and move on …
1