Series: Building the CRUD-builder

Pods

Published on Apr 26, 2015

Pods is another way to structure your files and folders. It's becoming more popular, and may be the default in Ember 2.0. In this screencast we explore some of the finer details of using pods in your project.


Links

Code

Transcript

Pods are a new way of organizing your directories and your files. It is becoming more popular, and it may even be the default in Ember 2.0, but before I show you how to create your file directory in a pod like structure, I want to show you the problem that it is trying to solve.

Why Pods

Let's say that we are trying to find all the files that pertain to a particular resource, in this case territories. In our traditional app structure, we would have to go through all these folders. There is probably not an adapter, but there probably is a controller, so we go down here, so we have that open. There is probably a model. You have to go in here and a route and some nested routes… as you can see, it is taking us a while to find all the code that is related to this one thing. It is spread out all over and so now we have it all at our fingertips after about 20-30 seconds of searching, but God forbid we open other tabs and lose track of these.

Pods vs “Classic”

Pods help us organize it so we only have to open one folder and we are able to access all of this. This is how a post and post resource would be organized under classic. Under pods, they would be organized according to resource, so we have our posts resource and then our post resource. You do not have to open one folder, you have to open two. That is way better than searching through five, six gigantic folders. We have the resource name and then the function of the file.

Let's see that within our app. We have our post folder which there is an index, so it has that and then our post folder with the model and the template. That is fairly simple and it follows this pretty well and we will see that our tags and our tag also follow this. Notice there is an edit and a show folder for the show and edit routes. The magical thing about this is no matter how many resources we have, tag and tags will still be right beside each other and I can just open up and work and have everything I need in an easily understandable structure and that is structure is really easy to understand when you are reading, but what about when you are writing?

Writing Pods

The first situation is, you have a resource. Let's say you have the tag resource. The model would go inside and you could put a controller or route or template inside. In this case, there is not direct template or router controller, but those do show up in the show and edit routes. You also have folders have folders for routes underneath the resource. Then if you want to do something like a partial, you can create another folder for it, so we call this partial tag/edit-fields which is in tag/edit-fields/template. Once again, the file names give you the job that it is doing and the folder names give you the route or the resource that it is at. We can go and see that this holds true for tags, as well. In this case, there is no model, because it uses the tag model.

You will notice that in the router, tag is nested under tags. However, each resource gets its own folder on the route directory when you are using pods. If you try to put tag under tags, then the model will not be recognized. That is how to arrange your files and folders for pods.

Customizing ember-cli

If you are using Ember CLI and you put your folders nested under app, then Ember CLI will automatically recognize them, but there are a few things you can do to customize it. In the command line interface, if you want to generate something using pods, you just add the —pod at the end.

If you are always going to be wanting to generate in pods then you can, in your dot Ember CLI file include the use pods true option. When you do that, then doing —pod will actually reverse it and make it so you no longer are using pods. So —pod switches whatever is happening and use pods sets the default to using pod.
If you want to have a different prefix than app, then in your config/environment.js you can set that, so you can have a folder specifically for your pods.

Limits of Pods and Resources

You will notice that under my app directory, not everything is a resource and that is for a good reason, because pods still are not good at handling everything. You can have your application folder which is pod based— you may not think of it as a resource, but it is. That does count as a pod.

You also have your components folder which when you are doing pod based components will come in handy. Those do not fit under resources. You have your helpers, because, where else are they going to go? You do not want to create a new pod for each helper. The same with initializers. Then you have the templates which are for miscellaneous things and shared partials, as well as your app index and router files.

Conclusion

So that is pods. They are (hopefully) the future of directory structures, and that future may be here as soon as Ember 2.0, as a default.

It is important to note that pods and classic directory structure are not mutually exclusive, so you do not have to convert everything over in a big bang. You can do it piecemeal. Good luck, and I'll see you next time.

Building the CRUD-builder

Subscribe to our mailing list