Using $resource for Data Models

Brett Shollenberger: Let's take a look at one way we can build models in Angular. We're going to build a post model using the built-in $resource provider. The first thing that we pass it is the API where we can grab posts, and we can parameterize it with the _id for MongoDB. The second parameter is an empty object because there are no default parameters. There's no default ID.

We can add arbitrary methods here. We'll add an update method because it doesn't come with that out of the box, and we'll probably want to send put requests. The last thing we do there is to return the model.

We've got a post model. Let's see what we're going to build with it. I want to build an interface that lets us add posts. It will let us edit posts, like this. We can refresh. We see everything's still there. And we can delete posts.

That's what we're going to build. Let's see how we're going to build it. We're going to pass in our post model, and we can start using it. We can add post to the DOM. That will be a new post that's going to be the post that we enter text in and save.

We can add posts to the DOM. We'll do that by querying the back end for all of the posts. That's given to us by $resource. We can add a save function that will be bound to the DOM as well.

Here, we're going to save whatever the current post is. That's what we're adding text into. Then we can push that post into the post array. Finally, we'll set scope post to a new post so that the form clears and we can enter a new post.

We can create delete basically the same way. This is another function we're adding to the DOM. We actually need to call post.delete. That's on the model. We'll pass in the post. We'll pass that in on the DOM.

Then we will remove this using lodash. We really should be waiting for a response from the back end to make sure that it's good to go ahead and remove it. For right now, we'll just do this. Looking good.

Let's take a look at what our DOM looks like here. We can add some fancy elements to it, like ng-show on the title and on the table, with post.length. As long as that is not equal to zero, those guys will show up.

We're doing an ng-repeat for that table to create each of the rows. We have things like active post, which is a method we haven't created yet, that will make the post. We click on the active post so that we can edit it.

We add the delete click event on that delete button. We can add an editing property to the scope that will tell us whether or not we're editing the post and change this title appropriately.

On our form, as we might imagine, we have an ng-submit with a save function. We bind ng-model to the current post. Remember, that's going to be this guy, the new post.

Our submit button, we don't even need to tell it that it has this ng-submit on it, because automatically it will bind to that. We add this new post button, if we're editing another post, so that we can clear the form there.

I won't waste your time writing the rest of these methods on film. You can take the rest of them from the notes and play with them yourself.

One of the big things to notice is that our controller's already getting pretty hefty. It's going to get unmanageable, given that we're going to have to do this for every single model. A lot of these things should be built into the model itself, like whether or not we should update or save based on whether or not we have an ID, whether or not we should add new posts to the post array.

Here, again, I haven't even added functionality to it that says, "If we get a valid response back from the back end, then we should add it." We should have a lot of this stuff taken care of for us, and $resource really doesn't fit the bill there.

One of the most conspicuous areas where $resource is lacking is in its ability to let us create business logic, which is something we'd normally associate with a constructor like we're building here.

We can start to overcome that by actually going ahead, building a constructor, and assigning methods that we would get from $resource, which I'm calling just the post methods right now, either to the instance or to the post constructor itself, which is what we'll have to do for something like query, delete, and all those other guys.

We'd still be missing a lot of functionality that we're going to need on every single model. We're going to need relationships. A post probably has many comments. We probably want to eagerly load them when we load our post. A post probably has validations. We shouldn't save a post if it's not valid. We should show the validations to the user on all of our forms, without having to add directives for all those things specifically.

In future videos, I'd like to explore how we can actually create a more robust ORM. Look out for that, you guys.