Transcript from the "Auth State & transitionTo" Lesson
>> Mike North: One thing I wanna point out, and we should look at this, to see if we've done this right. You have two options here for sending the user on their way to a new destination, transition to and replace with. And there's a difference between the two, but before I do that, has anyone ever found themselves in a web app?
[00:00:20] Where you hit the back button and it has trapped you in that experience. You hit the back button and it sends you forward, you hit the back button, it sends you forward. So that has to do with some misuse of the history stack, where there's a URL in your history, and all that URL does is forward you to a new location.
[00:00:38] So you go back and it forwards you, and you go back and it forwards you. I think it's quite possible we've done that, we've made that mistake here. Let's, sorry, teams, let's make sure that's the case, so I can go back here, that's fine, let's log in
>> Mike North: I should be able to hit back and I should end up in the tests, let me make this a lot more clear, I wanna start out outside the app.
[00:01:10] Sorry Google, and now I'm gonna enter the app and land on Teams.
>> Mike North: I wanna make sure I'm doing this right, it takes a little bit of thinking here, so I wanna be unauthenticated first.
>> Mike North: Cuz I wanna simulate the case where, okay, so we're unauthenticated. I'm gonna attempt to visit Teams, and it's gonna forward me to the login page, everyone follow?
[00:01:43] What I wanna make sure of, is that when I arrive at the login page and I hit back, I wanna be back at Google. I don't wanna be trapped in that login page, I wanna be able to leave the app, we don't wanna trap our users. So, let's try it, Teams, so it's really quickly done that redirect and the back button.
[00:02:03] Okay, good, this works properly, if it didn't, if it hadn't, we would wanna do replace with. And the difference is, transition to at the new item in your history, replace with replaces the most recent item in your history with whatever you're sending them to. So especially if you had like a multi step forwarding process or something like that.
[00:02:30] You would wanna make sure that you don't like, completely fill the user's back button with all of those meaningless history states. You want it to be meaningful milestones, and a good rule of thumb here is if you're building a server-rendered app like, with PHP or regular HTML, how would you like your history to look?
[00:02:51] Use that as your guide post, right? And the only advice I can give you, because this is nuanced, actually test the stuff out. There's no rule of thumb I know of where it's always best to use transition to in one situation. Always best replaced with another, test it out and think about what your users expect.
[00:03:12] So we'll leave this as transition to because it seems to work, and let's deal with log out. So we'll go back to our app.
>> Mike North: Log in, and I wanna wire up this Logout button, so first let's add this method in our service.
>> Mike North: Apps/services/off, and we're going to create a function called log out, and this is going to end local storage, clear, clear, looks like.
[00:03:57] Clear is clear, everything, let's do remove item, I don't wanna overdo here. So we're gonna remove that item from local storage and send the user to the login screen. Does that look reasonable to everyone, that log out probably means this? We can also make this an action.
>> Mike North: And for those of you who have been using Ember for a while, you maybe thinking, you don't usually put actions on services.
[00:04:53] So you can mix and match your vanilla JS stuff, leveraging these decorators, with components and services and framework concerns. So to make this logout button work, I want this team sidebar component to have access to the service. And currently, this is one of those components we created at the beginning with just an hbs file.
[00:05:19] So we're gonna need to do one of two things. But ultimately, we need access to this service in the template so that we can wire up the dom event for the logout button to this logout action we've just created. One, which we're not gonna do, but we could, is you could create a helper that gives you access to that service.
>> Mike North: And there's our question, so this, whenever you're using ember CLI's code generation, it's not gonna blindly write over stuff.
[00:06:23] In fact I could type d, and see a diff of what it wants to put in there versus what it would remove. Obviously we would lose a lot of content there, so I'm going to say no, I don't want to delete this. But this is a nice tool that you see over and over, even when you're upgrading an ember app.
[00:07:05] And here we'll import inject as service from ember service, and,
>> Mike North: There is our off and actually we don't even, we may need it later. But since we're using it into template and there's no autocomplete for this in a template, I'm less excited about putting this here, the comment.
[00:07:38] So finally team sidebar hbs, we're gonna go to that logout button, which earlier in the course we made this a LinkTo. Remember we just said, from now all we care about is I click log out and I find myself at the login screen. But now we need to do more, now we wanna instead of just using LinkTo, we wanna use the off services logout action.
>> Mike North: So that the local storage gets cleared along the way, right, without that we're not really logging out. User will refresh and they'll still be there, so let's scroll to the bottom of team-sidebar.hbs. There's our LinkTo, so we wanna keep our html the same and it turns out we'll need to put this back as a button.
[00:08:26] Cuz LinkTo is not gonna take care of our local storage concerns. So, I'm just gonna delete this, and we're back to a button, and we have to listen for a DOM event. What do we use for this?
>> Speaker 2: An on-modifier.
>> Mike North: On-modifier. Very good. What dom event should we listen for?
[00:08:48] All right, and here's something cool.
>> Mike North: We don't even have to let this component worry about handling this action, right? We're binding straight from this component's template, going into the service and landing on its logout action, that's pretty cool, right? I like the idea of actions and services this is nice, a lot less code that would just be sort of catching something and throwing it along the way, we don't need to do that.
[00:09:24] Just let it go where it needs to go.