 So my talk is called the legend of Zelda a link to the past see what I did there yeah so it has zero to do with Zelda but I just really like the name I kept chuckling every time I thought about it I couldn't help myself I thought that's freaking awesome and we got to do this at work as well so thanks to Paige you down the front it's awesome so I apologize to anyone who came here just to hear a talk about Zelda and ember because that's about as much as you get I'm really really sorry about that what I'm actually trying to hoping to tell you a while back Jamie sort of said on the forums that one of the feet one of the bits of feedback he got about this meetup is that those people kind of wanting some more begin that beginner type talk so I thought this may be useful so it's really about what happens when you click on a link to in an app so it's it's something we always do like in all our web apps we've got loads of links but I'm not sure how often people actually stop and think or how many people actually understand what really happens under the covers when you click on a link to and I came across a tweet a year or so ago from Alex match near that kind of had this big flow diagrams like holy crap that's actually what happens in the router and I thought that's kind of cool so I just wanted to explain a little bit about that really so first of all who am I I'm Aaron you can get me at either those two places there I am one of the maintainers of the embassy a lie deploy thing that Tom talked about earlier so if you're interested in deployment of your and perhaps jump on to the repo there we've got some cool cool stuff coming so it's going to be awesome I'm this guy's little this this little guy's dad that's Noah he wears features in my talk so so link to what does it actually do has anyone actually stopped to think about what it does I mean it puts a link on the page but nope okay well you might all learn something hopefully so traditionally I guess when we have a link in our server side apps it's just an href pretty simple really it just doesn't get get request the browser to get the next page that you're going to that's cool but in an ember app we have something slightly different produces the same sort of thing looks pretty similar actually but what does it actually do here's the picture the flow diagram I saw this is what a link to does simple clicking on a link I saw that I went wow so I kind of want to explain a little bit about what sort of happens there so imagine a scenario where we have this sort of router setup in our app we've got two routes we've got slash about slash FAQ and we've got slash about sorry slash users slash some ID slash profile so we can go from the FAQ page to a user profile page things to note we've got some nested roots here so we're going to have an about route and FAQ route and our user route here has a dynamic segment which is the user ID so this is all pretty standard stuff I'm sure you guys have all seen that so this is kind of laying the land of what we're what we're looking at here so we sort of look at what ember objects we sort of have here we've got our two routes about FAQ and users one profile with that comes well the application route we always get that for free every time we get an about route by convention which is responsible for the about part of the URL there and we get an about FAQ route and then over on another one here we have the user route which someone there and our user profile route so there the routes we would probably see in our app for these two two routes so so imagine we start out on the about FAQ route we're sitting on there and there's a link on there to say the user profile the current current route so our link to might look like this we're going to link to the user profile route and we're going to pass in the current user which is a model object we're passing that in so that's kind of important to remember that where we're providing the model for this profile user profile we're going to and we have a link on the page so what actually happens so basically the router kicks in and a transition object is created at the point we click and that's essentially like a promise that travels with us all the way through until we've gotten to our destination and there are sort of three phases that the router goes through the first one is the will transition phase and the second one is the model resolution and validation phase and the last one is the sync exit enter setup phase so I'll explain to each of those as we go so let's start with we will transition phase so basically what happens first of all when you click that link is it goes to the current routes that you're on and fires the will transition action so this is an action some you might have even implemented you don't need to but if you want to do anything in your route before we exit out of it and go somewhere else this is the place to do it so the route is going to go to each of your current routes of where you are and fire off this this will transition action so we can see it starts from the outermost route the faq route it's going to come in here and fire and you can see we're passing that transition object that I was talking about this is something that will travel with us to the end so at this point you might want to do something like check that the user has entered all the mandatory fields and if not you actually don't want to go to the next page you want to sort of stay where you are so you can sort of abort that a transition that transition at this stage by calling transition dot abort essentially the router will call it on the faq route if all is good we haven't aborted or anything we go on to the next one and we call will transition on the about route and then if that's all good we go to the application or it called will transition on there so these are these are all things that happen along the way give me it's an opportunity to bail out of that transition at any time if the transition isn't halted and everything's good then we move on to the model resolution validation phase so this is a phase that most you probably would have seen the roots allow you to override a few different hooks that you've probably seen before model model after model but a lot of people actually don't really even know what they're doing or why they're being called some people talk to think the model is actually just setting the model on the route but it's actually just a hook that you're overriding that ember expects to be there and if it's not it has some sort of default functionality so the idea of this phase is to collect the model objects for the route and then resolve them all in this case we have two routes we have the user route and the user profile route so it's going to go through and try and resolve what the model objects are for each of those route so I can set them on the controller and I guess it's important to note if you return a promise from from any of those hooks before model model and after model the breed is actually going to halt until that until that resolves so if you've got a call to an API in your model hook that takes 10 seconds to load your ember apps not doing anything until that comes back which is where you probably start to see the loading substates but that's kind of another another call another discussion but basically essentially it'll wait till those promises resolve until we get in so after the start of this thing this route comes in and fires the before model hook of your user route if you haven't implemented that's cool it's just an empty function under the covers but you can override that to do something you might want to check if the current user is logged in if they're not you want to abort that transition you want to go to the login page we don't want to go to the user profile because we're not logged in but if that's all cool then the next thing this one's going to do is actually call the after model hook so you'll notice we skipped over the model hook because well in our link to we provided that that user that user object we said we want to link to the user profile and here's the user model so because we provided the model Emma doesn't need to go and resolve what the model is for this route it's been provided already so it's so it's skipped over that one so if the after model of that that route is okay we jump into the profile route and we fire off the before model model and the after model hooks is this making any sense to anyone yeah cool everyone's probably familiar with these hooks right so you don't you can you can implement as many as little as as many as these as you like it's not like you have to put all these in your roots so then if all the all the models have resolved okay and there's been no sort of errors thrown or anything like that we go into the sync exit it's into setup phase so this is where it comes to clean up so we're we were in the about FAQ route we're just trying to go to the user profile route we've resolved all our models we know what our model data is for the new route we're going to we need to start to clean up now so first goes in and calls deactivate again it's another hook you can implement I've never had to implement this to be honest but if you want to do something on your way out of a route here's a place to do it so we can see that it goes in there calls in the about FAQ roots you can see again it's going from the right most route back in just deactivating all the routes we're currently on before we go and activate the new ones we're going into then we come into our user route we have a chance to do something here on activate again I haven't had to do anything there but set up control is pretty common most people do this this is where by default the the router will take the model that you've returned from your model hook and set it on your controller and then around this stage it'll it'll call rendered template say here's the controller here's the template go and render yourself but this gives you a bit of a chance to do some other things set up some other controllers maybe set some other data on your controllers if you need to an important thing with this one is the router does have some default functionality for setup controller so if you are going to override this make sure you call super on it because by default it will set the model that you've returned from your model hook on the controller for this route and if you don't call super dot no call super on it then you're not going to get that model set so that's kind of a little gotcha there so after doing on there we end up calling activate on our profile route and activate setup control on our profile route so there was a lot of stuff happening transition complete and at any point in those in that model resolution phase or the setup can sync phase if an error occurs the transitions are boarded and then the error action will be called on your route so I don't know if you've if you've ever implemented that or seen that but basically if you have an actions hash with an error function that will get called on your route if that's not handled there or bubble up to the next route bubble all the way up so that's what'll happen if you throw an error or reject the promise in any of those things so that was a whole bunch of stuff and diving into like little bits at a time so this here is trying to just look at it from a higher level of what we actually did there from clicking on that one link what actually happens so basically we we go and fire off any will transition hooks from our current routes that we're currently on the about the FAQ routes if they're all good we go through and we resolve all the models on our new routes we find out what they are we go and get the user if we need to or in this case it was provided we go and get any profile stuff that we need to we resolve those in our before model model and after model hooks next thing is we go and deactivate all our old routes the ones we're leaving and then finally we come in and we activate any of the new routes we're going into we call setup controller we put our model stuff model objects onto the controller and we render the templates and that's about it does anyone have any questions in terms of the synchronous behavior that you know basically you want to it's going to wait until the models are completed before it moves to finish the transition yeah in your example you had the user object and the profile object or the user model and then the profile model are those asynchronous and then they just both have to be resolved so the first one no it'll it'll fire the user route and then it'll wait for a promise to be resolved before even if you have a promise only before model and model the before model or wait before it hits the model and then it'll do the after model and because like the after model hook is actually past the model object as an argument so yeah it waits till it's resolved and so then it will go into the profile route but are there any real dependencies between those two different independent models I mean it seems like you could do those in parallel well okay so if you think of users and then user the user's route will fire and get the list of users and then your user route will generally get an id from like it's not going to go to the server and get it it's going to get it from your cached list so there is a kind of a dependency there right so you're going to wait till you got your list of users say in the data in the cache and then going to get the user for id one it's right there so yeah I suppose there's an invested relationship it's probably dependent and that's exactly the reason they are nested in the router is because there is a relationship there if they weren't related like that then you wouldn't nest them you can still have the nested URLs but if they were if you if you clicked on the user and went to a different page you don't need the list of users so there's no real relationship there and that's I guess the intricacies between nested templates and nested URLs in the router which is another discussion as well right yeah just putting in our errors only relevant to building up to what are the also like uh or whether we raise it's not the exit they could be raised an x as well yeah and the transition will abort at that stage yeah yeah yeah or you can call transition.abort if you if you want to as well yeah what's the best practice in terms of stuff and controller is it is it is it the best practice to keep everything in the model as opposed to the controller so like do all the logic that's required on the model or um or just check out if it's a controller uh I don't know what the best practice is um I generally return what my model is from the model I'm just trying to make better one liner like here's the model and then if I need to do anything else do that and set up controller and so um yeah I mean I don't I try not to do much and set up controller if I can help it because I feel like yeah I'm not really sure what the best practice is to be honest as little as possible yeah basically it's going away the root the idea of the root okay right what are you really trying to say so actually on that point there's an rfc at the moment yeah for what useful components will look like so if anyone's interested in having a little glimpse of what what your roots will look like in m2 that's the current best guess it's pretty likely it'll go that way and it's existing moves won't break in m2 they'll carry on working more or less but there are the the idea of a model that's being exploded out to like uh naturally beats um so if running to things in the past where there's differences between clicking on a on a link to go to a root and accessing the root directly through like a actually can you talk about um uh so I guess if you think about it like I don't know what issues you have or differences but like if you think about it if you're going via the like clicking on a link so say for instance you have a list of posts and you don't want to go you click on a link to go on a particular post at that point you will already have your collection of posts so um you can go into the new post you're just really pulling something from the cash but if you're going from the url it's actually going to fire the the route for your post route and then your particular post so you can I have seen issues there where it's not exactly the same because when you transition from posts to a particular post you're not activating and firing that post route because it's already been fired and you're just becoming more specific by going to the post route does that make any sense yeah whereas you're coming from the url you're you're actually firing I think the sequence of events is yeah exactly yeah so different stuff's actually happening or more stuff's happening when you go in via the url because you're essentially loading from a clean slate so it needs to activate the application route the post route and then the post route whereas if you've come in via a link you've already activated the application route because you've got there somehow you've got to the post page so you've activated that route it doesn't need to reactivate it so there is slightly different stuff happening under the covers and you can get different issues that way I don't have to answer your question also there's two ways of what you're doing voting some people prefer to do it via a link to helter whereas others they're just doing behind the scenes they just essentially trigger an action yep yep that's another way to do it right yep but it's really bad privacy to do it by action because then you lose the you know google and the course yeah obviously sometimes it's not important if it isn't right it's better to use the object because yeah it can follow yeah yeah under covers that'll be doing a similar thing so we're basically creating a transition object and transition between but yeah in terms of SEO and stuff that makes sense yeah does anyone else have any questions so if you're doing say link to users slash ad yep no you can pass like the literal model that's the second argument to link to can you pass the you can yeah yeah yeah I think you need to then implement the model I'm pretty sure you get the idea and you need to return the model of that stage but yeah you can pass the although it may because by default the model hook is implemented to to search for a dynamic segment and use that as the idea to get a resolver model so it may actually do for you magically because that's what happens if you like or don't don't create a root nor do generates it for you it will return for you it kind of knows that when there's a dynamic segment you probably want to retrieve the model for the same name with that id no one else yeah sure yes so um this is who I am that's where you can get me and um I wanted to give the people that came for zelda a little bit of something so um yeah here's a surprise for you she's took me forever