Flexible Flash Notifications with Inertia

Sign in Get started

This episode is for members only

Sign up to access "Flexible Flash Notifications with Inertia" right now.

Already a member? Sign in to continue

Playing

06. An easy refactor for different notification types

Episodes

0%

Your progress

Total: 28m
Played: 0m
Remaining: 28m

Join or sign in to track your progress

01. Introduction and demo

02. Quick Inertia setup

03. Basic notification flashing

04. Automatically picking up notifications in Inertia

05. Using a package to show notifications

06. An easy refactor for different notification types

07. Refactoring for ultimate flexibility

Transcript

00:00

So there are a couple of different ways that we can handle how we're passing down the type. We can either infer this from the key that we use to flash this in the session,

00:10

or we could pass an array down here with the body and the type explicitly. Now, whichever solution you choose, it really doesn't matter. We're going to work on the easier solution in the first part here. And in the next episode, we're going to look at a slightly harder to build,

00:26

but more flexible solution going forward that might save you a little bit of time. OK, so to work on this solution, we're going to go ahead and change over the key to notification. Now, we need to update that over in handle inertia requests here. And we also need to update what we're passing through,

00:43

because now we have no way to define the type. So now I'm going to pass an array down here, and I'm going to set the type here to success. And I'm going to set the body here to that worked nicely. And that's it.

01:00

So now we have effectively an object in here by the time it arrives into our notification plugin. So let's get rid of the toast notification. And let's just console log out the notification in here and see what difference this makes. So you can see here that we've now got an object with a type in here and a body.

01:19

So what we can now do is very easily just put this directly into here. So notification dot body. And in here, we can say notification type. And it's really important at this point to check if we actually have these things available.

01:34

So we're going to create an if statement in here and just say, if notification body and notification type, then we do this. If we don't have either of them, there's no point. We don't have any data in here to work with.

01:46

So if we come over, hit do something, we get a success with that work nicely. And with this done, what we can now do over in here is change this over to error and say that failed nicely. And of course, as you'd imagine,

01:59

then two variables switch around and we get through an error with a new message. Now, I don't like the way of doing this just because it clutters up things inside of my controllers. And in this case, I'd much prefer to say success

02:15

or error or whatever we want to give inside of this key and then just provide the string of the body. Saying that, let's push ourselves a little bit and head over to the next episode and look at a slightly different way that we can do this and clear all of this stuff up.

Episode summary

In this episode, we look at a simple way to refactor our notification system so it can handle different types like "success" or "error". First, we discuss a couple of ways you could approach passing notification types down to your components. One way is to just use the key you flash in the session; the other (and the one we implement here) is to explicitly pass both the notification body and its type in an array or object.

We update our code so that instead of just having a message, we now pass an object with a type (like "success" or "error") and a body (the actual message). We then update our notification plugin to read from this new object, making it easy to display different types of notifications. We also add a quick check to make sure both body and type actually exist before trying to use them.

With this in place, we can easily show a "success" notification or switch it to an "error" notification, just by changing the values we pass in. At the end, though, we mention that this method can get a bit messy in controllers, so in the next episode we'll explore an even cleaner, more flexible way to manage notification types!

Episode discussion

No comments, yet. Be the first!