Add type information for inbound messages on the DeviceChannel

[lawik]

No description provided.

[joshk]

I was looking over the spec for the handle_in functions and see that strings are required, which means we can't use atoms for the first argument https://hexdocs.pm/phoenix/Phoenix.Channel.html#c:handle_in/3

[jjcarstens]

I dug into the serializer and more about the Phoenix.Channel behavior based on Josh comment and I'm unsure what to about it. There seems to be lots of partial enforcement of string and not-string. It seems we don't get much out of converting atoms and types at that point since most everything about the channel is overly generic.

The main gain is the documentation of messages. I think that is going to be split between server and extensions, so I'm not sure the best way to represent yet

[jjcarstens]

I'm assuming this is a dialyzer fix? We should prob include this in a different PR so its away from these changes

[lawik]

Yeah, dialyzer

[jjcarstens]

Suggested change

	types
	|> Enum.map(fn type ->
	try do
	String.to_existing_atom(type)
	rescue
	_ -> nil
	end
	end)
	|> Enum.filter(fn type ->
	if type in @valid_types do
	true
	else
	Logger.warning("Received invalid type for connection_types: #{inspect(type)}")
	false
	end
	end)
	for {type, type_str} <- Ecto.Enum.mappings(Device, :connection_types), type_str in types, do: type

We can use the Ecto.Enum mappings to get the valid types out of this. I'm unsure we need to warn on invalid being included? (this would mostly be hidden to the users anyway)

[lawik]

Just figured we'd do something when we see weird things :)

Would Ecto.Enum be smoother somehow or are you thinking full-on embedded schema?

[lawik]

So with handle_in having that spec, yeah. We should not re-use it the way I'm doing. We can delegate to an internal function that does the equivalent thing though. So not a huge deal :)