Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete Presence support #22

Closed
saschatimme opened this issue Apr 3, 2017 · 4 comments
Closed

Complete Presence support #22

saschatimme opened this issue Apr 3, 2017 · 4 comments

Comments

@saschatimme
Copy link
Owner

This Issue is to keep track of the remaining work, to get full Presence support building on the PR #18

Missing implementation details

From the docs

Additionally, every metadata entry will contain a :phx_ref key which can be used to uniquely identify metadata for a given key. In the event that the metadata was previously updated, :phx_ref_prev key will be present containing the previous :phx_ref value.

Where is it necessary? (see API discussion below as well on this point)

From the docs

More detailed information, such as user details that need to be fetched from the database, can be achieved by overriding the fetch/2 function. [...] The function must return a map of data matching the outlined Presence datastructure, including the :metas key, but can extend the map of information to include any additional information.

The current implementation has only support for the :metas key and would ignore any other keys.

API

The current API is (in the Channel module)

onPresenceChange : (Dict String (List Value) -> msg) -> Channel msg -> Channel msg
onPresenceChange onPresenceChange_ chan =
    { chan | onPresenceChange = Just onPresenceChange_ }

Some of my questions

  • Are there use cases where it should be necessary to have access to the :phx_ref or :phx_ref_prev values? Currently there would be sometimes a phx_ref_prev key in some Value. But since the phx_refs are not exposed it would be useless.
  • Would it be sensible to directly decode the Values i.e. that it would be more like
onPresenceChange : (Dict String (List MyVal) -> msg) -> Channel msg -> Channel msg
onPresenceChange onPresenceChange_ chan =
    { chan | onPresenceChange = Just myValDecoder onPresenceChange_ }

I'm probably missing some more things...

@opsb
Copy link
Collaborator

opsb commented Apr 3, 2017

I did have a look through https://github.com/phoenixframework/phoenix/blob/62f18c71888ce700cc86933296e619f8a9dee0be/assets/js/phoenix.js and noticed that it doesn't actually use phx_ref_prev. Even grepping prev across the whole project only turns up a single comment https://github.com/phoenixframework/phoenix/search?utf8=%E2%9C%93&q=prev&type=...

@knewter
Copy link

knewter commented Apr 3, 2017

  • phx_ref is an implementation detail re: the communication protocol and no one should care about it from userland.
  • agreed, I never saw phx_ref_prev in my research when doing my implementation for elm-phoenix-socket
  • I'd think you could give a version to the user that doesn't include the phx_ref bits since they are a bad idea to care about in userland

My implementation is here: fbonetti/elm-phoenix-socket#16 if that's useful

@saschatimme
Copy link
Owner Author

I just pushed a new API with a dedicated Presence module. The plan is to get some feedback from @opsb (and anybody else who reads this :) ) before a official release.

@saschatimme
Copy link
Owner Author

Just released 0.3.0 official.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants