Add presence

[jur0]

This adds support for Phoenix presence.

There is a new callback onPresenceChange in Phoenix.Channel module. The callback is called each time there is a presence_state or presence_diff event. The callback exposes the current presence state as Dict String (List Value). It is a dictionary where the key is presence key (such as user id) and the value is a list of payload data such as [{ phx_ref = "y6aMeMQNuR8=", online_at = "1490470085" },{ phx_ref = "LGFol1M18BM=", online_at = "1490470085" }] (each user can be connected more than once so we track that).

The presence state is updated internally on presence_state and presence_diff events.

[saschatimme]

that's really cool!
Just want to let you know that I'm a little bit short on time at the moment, but @opsb will do the review.

[opsb]

Thanks for this @jur0! I'll most likely review tomorrow.

[opsb]

@jur0 it would be great to see this running, could you add something to the example app?

[opsb]

Having something in the example app would be sufficient but some unit test coverage on https://github.com/saschatimme/elm-phoenix/pull/18/files#diff-58ad5ceac6b844a5376bf0b35cb0cc68R45 would also be very helpful. The testing situation is far from ideal at the moment (Tasks make it tricky) but this seems like a good spot for some tests. I did get as far as setting them up in https://github.com/saschatimme/elm-phoenix/pull/19/files but it's probably easiest to just run elm-test in the root and go from there. No worries if that's too much work though, I'm not too familiar with Presence so it would be a good exercise to add the coverage myself later.

[jur0]

I will update the example app with the Presence so you can check how that's supposed to work. It might be done tomorrow.

[opsb]

Thanks @jur0!

[jur0]

Hey @opsb. I created a new repo with the example: https://github.com/jur0/elm_phoenix_example

There is no ElmPhoenix.OnlineUsers module anymore as it is handled by Presence. Also, a user with the same name can have multiple connections at the same time (which is tracked by Presence). There shouldn't be any other significant changes.

I didn't change the example in this repo as it is an old version of Phoenix and it'd be too much work to update it I think.

[opsb]

Thanks @jur0, I'm a bit short in time tomorrow but I'll try to take a look. If not it'll be thursday for sure. I've started putting some elm-test coverage together so I'm already up to speed with Presence.

[opsb]

Hey @jur0, this is looking really good! One thought I had though, I think the state should be decoded before it's passed to the Msg e.g. at https://github.com/jur0/elm_phoenix_example/blob/master/assets/elm/src/Chat.elm#L193 do

Channel.onPresenceChange presenceStateDecoder (\presenceState -> UpdatePresence presenceState)

presenceStateDecoder : Decoder PresenceState

What do you think?

[jur0]

Yes, it'd be better to have something like:

type PresenceState
    = Dict String (List PresencePayload)

type alias PresencePayload =
    { phx_ref : String
    , online_at : Date
    }

and a decoder for all of that. Would you like to add it or shall I do it (might take a couple of days though)?

[opsb]

Also, I had to change https://github.com/jur0/elm_phoenix_example/blob/master/assets/elm/src/Chat.elm#L171 in the example app

[opsb]

@jur0 I'm taking a long weekend so I won't be able to look at it until next week. Happy to pick it up sometime next week if you haven't had a chance though.

[jur0]

Ok, in case I start working on it, I will post a message here so both of us won't work on the same thing.

[opsb]

@jur0 I've been giving some thought to the API and it's not really clear what the best approach is (mainly because I haven't actually used Phoenix Presence yet). I think we should perhaps merge this in as is and see what patterns emerge. @jur0, @saschatimme let me know if this seems like a reasonable approach and I'll go ahead and merge it in.

[saschatimme]

I think, if an API change wouldn't cause a major internal change that we should merge it for now @opsb.
Afterwards we can still figure out the best API. Is this okay @jur0 @opsb?

[opsb]

I think any refinements will build on this API so I'm just going to go ahead and merge.