Building a Notification Preference System in Laravel
This episode is for members only

Sign up to access "Building a Notification Preference System in Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
08. Initial notification preference state

Episodes

0%
Your progress
  • Total: 1h 23m
  • Played: 0m
  • Remaining: 1h 23m
Join or sign in to track your progress

Transcript

00:00
Now that we're confident that we can store these preferences, let's look at displaying what should
00:05
be checked on the UI. So at the moment over in the database we've got no notifications stored, let's store some. Of course we're not going to see these reflected on the front end but then we can go ahead and work on checking these. So for a new project is created I'm going to choose both of these, a project is overview or overdue I'm going to choose slack and then let's just choose all of
00:27
these for files. Okay that looks about right, let's go ahead and save this out and we know that that should be stored properly over in the database. Now our job is to actually display whether these are checked. So over to the edit page, just underneath here where we've created our input we want to output a checked state. So for this specifically within blade we can use checked,
00:52
if you're using livewire you can do the same thing and of course with view you could use checked and bind this in based on what you've passed out as a prop. Okay let's go ahead and use checked in here and what's the condition? Well the condition is that the channel type, so let's say in array and channel types and notification channel type which is going to be
01:14
something like email, slack, sms is within my notification preferences for this specific notification that we are iterating through. So although this is going to look a little bit messy it's not too bad. So we're going to say auth and user, so we're going to grab the authenticated user out, we're going to grab the notification preferences directly from that user, we're not
01:36
going to grab the relationship, we're going to grab the collection here and we're going to use find on the collection. So we're not going to do this, we'll take a look at our database queries in just a moment but we want to find within that collection the notification id. Now that might not be found because we don't store notification preferences for every single preference,
01:58
only the ones that are potentially checked. So we will optionally access out the pivot because otherwise we might get a null value back from find here in which case we wouldn't be able to extract the pivot and then we're going to say channels. So basically is the channel that we're iterating through within the channels that the user has stored. Now we need to fix this up here
02:22
so we'll get rid of this and add that on the end there. So basically all of this, this in array goes within checks and we're checking if the notification channel type is within the list of channels the user selected. Now again channels might also be a null value so we can go ahead and optionally bring out a empty array if that is not filled. Now this should be enough to go ahead and select
02:50
everything in the UI that we just chose but the question is are we running maybe one too many database queries here? Let's go ahead and check this out because that's a really important part especially when we're iterating through here and looking within relationships and then we should be good. So let's do a composer require on Laravel debug bar. I have this open here if you've not
03:14
used it before it's just going to give us stats about queries, views, all that kind of stuff. Once that's installed it's automatically available here for us and let's take a look. So you can see here we do have eight queries which might seem like a lot just because a lot of the stuff that we have set up by default in Laravel uses database but we are not duplicating any queries here so
03:35
we are not going through and running a query for each of these checks and we do not have an n plus one problem which is great. So there we go that's as simple as that checking the notifications that we have in the UI and of course when we go ahead and change one hit save that just stays exactly as we selected.

Episode summary

In this episode, we're tackling how to display the user's saved notification preferences on the UI. We kick things off by checking what's currently in the database and adding some example preferences so we have something to work with. The goal is to make sure the correct checkboxes are selected when the user edits their preferences.

Next, we walk through updating our form so that the checkboxes are checked based on what's stored for the authenticated user. We break down how to fetch the user's notification preferences and use the checked attribute in Blade (or your JS framework) to reflect the saved state for each notification type and channel. We handle cases where preferences may not exist yet, making sure things don't break if there's missing data.

Finally, we make sure we're not being inefficient with our database, running unnecessary queries for each checkbox. To check this, we pull in Laravel Debugbar and verify that there aren't any N+1 query problems—everything is running as it should!

By the end of this episode, you've learned how to accurately display the initial notification preference state in the UI, keeping everything performant and tidy under the hood.

Episode discussion

No comments, yet. Be the first!