NOT TO BE MERGED - just using this for comparing diffs#2
Open
gjaldon wants to merge 3 commits intoLearnPhoenix:masterfrom
Open
NOT TO BE MERGED - just using this for comparing diffs#2gjaldon wants to merge 3 commits intoLearnPhoenix:masterfrom
gjaldon wants to merge 3 commits intoLearnPhoenix:masterfrom
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.