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

NOT TO BE MERGED - just using this for comparing diffs #2

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

gjaldon
Copy link

@gjaldon gjaldon commented Sep 16, 2016

No description provided.

We want to start recording anonymous users so we can store
relevant data such as a fake name, fake avatar, and when
their chatroom was last viewed by an admin.

We generate the relevant migrations and add the fields we
need for an `anonymous_user`. Since the frontend generates
a UUID for every anonymous user, the UUID would be perfect as
`id` for our AnonymousUser records. We use the `uuid` type
for the `id` column of our AnonymousUser and set it to
not autogenerate an id. That way, we use the UUID passed to
us from the frontend as `id` every time we create a new
AnonymousUser record.

Now that we have an AnonymousUser, we can associate it with
Message so we can easily get all the messages sent by a user.
Note that there are a few extra steps for this because we
are using a `:uuid` type as `id` instead of the default
`:integer`.
We make sure that an anonymous user is recorded in
our DB when a user joins the "admin:active_users" and
"room:#{room_id}" topics. Both are possibly the first
entry points to our app for our user.

Our anonymous users are passed as a 'lobby_list'
to the frontend when an admin joins the "admin:active_users"
topic so the sidebar can be populated with these users.
Now, our admin can see users they've chatted with over
the week/month/year!

The "lobby_list" event is only meant for admins. To
ensure that only admins receive payloads for this event,
we `intercept/1` it and use `handle_out/2` to filter
only the admins with the same public key as the user
will receive the event.

Note that we extract public functions that are used or
will be used in both AdminChannel and RoomChannel.
Keeping our channels clean of public functions that
are not callbacks is a good way to keep them clean
and maintainable.
We expect "previousRoom" and "nextRoom" in the payload
when a user joins a room topic. We use this to record
a timestamp of when admin has viewed both rooms. This
means we record when an admin both leaves a previous
room and joins a new room.

We then publish two more events every time an
anonymous user sends a message. The "lobby_list" event
for updating the user's last message sent and timestamp
and the "notifications" event for triggering browser
notifications. We'll get into more detail on that
once we work on the frontend.
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

Successfully merging this pull request may close these issues.

1 participant