Lessons 30-33 #3
Open
Conversation
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
|
The commits and what lessons they are related to:
Btw, about https://learnphoenix.io/#/phoenix-chat/listing_active_and_inactive_users.md
|
We want to start recording anonymous users so we can store relevant data such as a fake name, fake avatar, and more later on. 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`.
When an anonymous user joins admin:active_users topic, we make sure that user is saved to our DB. Also, we no longer track the presence of admins to simplify our code especially in the frontend (no more filtering out admin's id). We also add a simple validation on the params passed on socket connect. We raise an error if both id and uuid params are empty. That way, code that gets executed in channels can expect that a socket.assigns will always have a non-empty user_id or uuid. This helps to simplify our code too and informs the frontend that an id or uuid param is expected.
Defining a @derive module attribute is a convenient way to customize/instruct how Protocols treat our struct. We use @derive for Poison.Encoder in our Message and AnonymousUser struct so that Poison knows which fields to include when it encodes it to JSON. This saves us from writing a bunch of code for specifying which fields to include in our JSON version of our structs. Apart from specifying the fields for our JSON payloads, we also pass the most recently active users as lobby_list once admin joins the admin:active_users topic. This allows the frontend to load an initial list of users in the sidebar for admin.
We broadcast to admins every time user connects to our app via the lobby_list event. Our frontend will then be able to listen to this event and handle updates accordingly. This event will get triggered every time a user joins the admin:active_users topic so it will be up to the frontend to check whether a user is already on the list.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.