Sending :ecto_watch as the first element in message tuples

[cheerfulstoic]

Brought up in #19

The idea being that messages would have :ecto_watch as the first element:

def handle_info({:ecto_watch, :inserted, MyApp.Accounts.User, %{id: id}}, socket) do

I'm not necessarily opposed, but I did think about this and avoid it on purpose when creating ecto_watch. My thinking was that the library should be taking the place of something that you might have written yourself and just send the basic details about about record insert/update/delete. Since you have to subscribe to the messages and because the PubSub topic is ecto_watch-specific, it seemed fine to do this 🤔

Another possibility is to use a struct like:

def handle_info(%EctoWatch.Event{:inserted, MyApp.Accounts.User, %{id: id}}, socket) do

I often think of structs as just a fancy way of tagging data in the same way that you might do {:tag, data}. Since a struct is really just a map with an extra "hidden" key

I also like that because a developer wouldn't be required to match on the struct, they could normally do this:

def handle_info(%{:inserted, MyApp.Accounts.User, %{id: id}}, socket) do

... but if for some reason it conflicted with other messages that they might send then they could be more specific to look for the struct.

@frerich + anybody else?

[cheerfulstoic]

Just realizing that, of course, structs have keys, so it would need to be something like:

def handle_info(%{schema: MyApp.Accounts.User, update_type: :inserted, data: %{id: id}}, socket) do
# or...
def handle_info(%EctoWatch.Event{schema: MyApp.Accounts.User, update_type: :inserted, data: %{id: id}}, socket) do

But having keys feels like too much suddenly 😅