2.1 Starting With Simple JSON
1.Introduction2 lessons, 04:13
2.Getting to Know Falcor7 lessons, 52:40
3.Conclusion1 lesson, 02:31
2.1 Starting With Simple JSON
Before we start digging into Falcor and how you actually use it, we're gonna talk a little bit about JSON and its structure. And maybe how we would start to build out a little bit of a model within our typical REST API before we started switching over to something like Falcor, to handle some of that work for us. How would our model of our application begin to look? Well, since we're building maybe a simple todoList style application we would start to think about what is the representation? How is that data structured into some sort of model that you would ultimately then present to the end user? So we can start to build some of that out here just using JSON. So we're gonna go ahead and create a model. So I'm gonna say var model is going to be equal to, and this is going to be a dictionary. And I'm gonna create a new dictionary of several different types of properties. So maybe within our model we have a property called, todoList. And in here we're going to have a number of actual todoLists objects. And so within here we're gonna create an array and within this array we're gonna have a couple of different types of todoLists, so maybe we can categorize these todoLists in a couple of different ways. And each of these categorizations is gonna have maybe a name. So in this case we could call the first one. Maybe this is gonna be recently viewed, so maybe I'd looked at a couple different types of todoLists recently. And so that's our name and then within here we have a list of todo items or we'll call them todos maybe. And within here we're gonna have another array of a series of objects and I'm just gonna populate this with a single object to begin with. Just so you can kind of get the feel of what this is going to look like. So maybe this particular todo object maybe has an ID. 12345 will be this one. Maybe it has a name. And in this case, we'll call this one Watch Tut's Videos. And maybe it has a completed flag to let you know whether or not you've actually done that yet. So we're gonna put that as false. So you can create additional todos within this list if you would like, and that would be fine. So then let's also say here that we have another list within here and this is going to be another object. And this object is once again going to have a name and maybe this is recently added or maybe new or something like that. So you have a couple different types of lists the ones that you've recently viewed to maybe some new ones that have been added recently. And this one is also going to have todo. So it's gonna have a similar structure, this is going to be an array and within here, we're going to create some more. So I can say I have another ID here, maybe 98765. And the name of this one is going to be, Get a great job. And maybe this one completed, maybe this one is false also for now. So this is the basic structure of our model. So nothing too crazy. And this model could really be anything that you need for your application. But like I said maybe we're building this really great todo application, that's really gonna help a lot of people get organized. And be able to structure these todo items. You can build these out as much as you would want. So in order for us to traverse through this model and be able to get things out of there. We can start to pick apart this JSON format and start to maybe print things out just to see what sort of data we have there. Now I'm not worried about presenting anything in a very fancy way here. I just wanna kinda get in and out of this data a little bit. So I'm just gonna use our console.log function here. And I simply want to print out maybe the name of the first todo item in the first todoList, something like that. So the way that I would do that using straight JSON syntax or straight JSON formatting here is I would refer to my model. And then I would go into my todoList property, and this property is an array as you can see here. And so let's say I only wanted the first one. So, I wanna go into the first object of that array, which is this one right here, which is the recently viewed. And then I wanna get the first todoList, and I only have one in here. Or the first todo item, I only have one in here for now, but that should be fine. And I'm gonna refer to todos, and I'm wanna get the first one which is going to be Index zero and then I wanna get the name so I'll say .name like that and go ahead and put a semicolon in there. So let's go ahead and save that. So I'm gonna jump over to my browser here and I'm gonna refresh my page. And as you can see nothing happens because I'm not actually using any HTML to present anything to the user but what I can do is I can come over here into my developer tools. And I can take a look and see what's actually going on here by using my console down at the bottom here because I did the console.log, as you can see here. It says watch Tut's videos. So just to show to you that this is not cheating, I can then switch to the other one. So let's say I want to go to the second todoList, which would be this one down here. So I could use index one like that and go ahead and hit Save and pop back over here. Let's refresh our page. And it says here Get a great job. So in the in most cases this doesn't seem like anything too out of the ordinary, simply because what we're trying to do here is create this JSON object that you would typically get back maybe from a REST API. Maybe you've been building, and then you can go ahead and parse through that JSON response that you get back. Now this is a fairly decent model. It's a common model. And if you've watched any of my other Tuts videos over the years, you'll know that I'm a big fan of building APIs and REST APIs. But you definitely run into some issues doing things this way. Simply because how do you structure those APIs, right? How do you continue to make them as restful as possible without stepping over into the world of RPC? And how do you keep your models separated enough and are your APIs getting littered with different URL parameters and things like that? And those types of things can be very complicated to deal with and so what Netflix has done using this Falcor concept is to kind of move a lot of those pieces around. And really simplify the calls that are being made from the client to the server so that you can be very specific about what it is you want. So in this case I'm asking for just a name now in the world of a REST API, typically what I would do is Is I would make an HTTP get request to a specific resource, add a URL and I'm going to get back whatever it is the server determines is the information that I want to receive. I really don't have a lot of say in what I'm getting back. Now that gets back into the idea of I can start to pass in additional URL parameters and maybe try to specify things that way but then that requires a lot of server side work where the server side developers have to now go and change a lot of that information and send different objects back well. What if I only need that piece of information from that resource but all the other thousands of developers on the front end don't need those things. So things can get kind of messy very quickly. So wouldn't it be nice if I could do something very similar to this. Where I could basically just give a path to the piece of information that I want and get just that? It would lessen a lot of the effort on the client side to be able to present that to the end user, as well as on the server side to be able to return just the required pieces of information that the client wants. And that's exactly what Falcor is gunning for. So in the next lesson I'm gonna show you a little bit how we take this very simplistic code here and adapt it into the world of Falcor.