Ember 2.x

Ember 2.x Folder Structure


This course has been updated! We now recommend you take the Ember Octane Fundamentals course.

Check out a free preview of the full Ember 2.x course:
The "Folder Structure" Lesson is part of the full, Ember 2.x course featured in this preview video. Here's what you'd learn in this lesson:

The resources for an Ember project reside in the /app, /vendor, /public, /tests, and /config folders. Other folders in the project are managed by ember-cli. Mike looks at the anatomy of an Ember application and spends a few minutes talking specifically about the /app directory.

Get Unlimited Access Now

Transcript from the "Folder Structure" Lesson

>> [MUSIC]

>> Mike: So we're gonna jump into what an app looks like here, and then we're going to create an app of our own. And a common reaction when you get started is that there are a lot of folders to deal will, a lot of folders and a lot of files.

[00:00:24] So you will see these folders and on the top we've got app, which is the source code for your application. A lot of time spent in the app folder, right, that's where all of the objects you defined exist. Vendor is a last resort for assets, this is where you're writing a shim.

[00:00:45] You're trying to get PhantomJS 1.9 working and it doesn't support function bind, and this is where you would put that kind of thing. Public is sort of a pass-through, it's a good place for images, things like that. Whatever you put in here will be unaltered and published with the distributed build of your application.

[00:01:05] The tests folder, it is what it sounds like, that is where all of your tests exist. And then the config folder, there's one file in there that is a place to define the configuration of your app on a per-environment basis. So if you wanted to say, I want extra logging in development mode, that is where you would put this kind of thing.

[00:01:30] You'll also see a whole bunch of other folders, ignore them for now. These are managed by the tool chain. They contain things like dependencies, our bower dependencies, intermediate build results. And we can take a look at what's in this folder but you will never need to touch it not in the first year of working on Ember.

[00:01:54] I don't expect that you'll need to take a look in there. So if you look in the app folder, which is where-
>> Speaker 2: There was a question.
>> Mike: Yes.
>> Speaker 2: On data persistence.
>> Mike: Yes.
>> Speaker 2: They're asking is Ember Data built from another DB or its own.
>> Mike: Built from another DB.

>> Speaker 2: I think they're asking, where does it come from?
>> Mike: So, Ember Data is not strictly part of Ember, you can use Ember without Ember Data. But Ember Data is just a conventional means of interacting with a restful service, restful API. It has some internal caching built into it so that if you now a record of this type, I don't expect it to change within the time frame of when the user is using this application.

[00:02:46] That is the layer where you can say, don't refetch this, just return what you already have in memory. It's where you can define relationships between objects, and the idea is, with Ember Data, it gives you the ability to define the how, in terms of interacting with an API.

[00:03:05] And then you can just deal with manipulating records and accessing properties on records. And then the appropriate API requests will be sent out automatically. So, it lets you kind of establish how to interact with the API, and then you don't have to worry about it. You just say, tell me how many items are in this to do list and it will make the request that's necessary, lazily fetching that data and then returning the result to you.

[00:03:36] We'll get to that in detail, it's a little hard to explain in a one minute answer here. So looking at what you'll see in the app folder here, we have a place for templates, a place for things called routes which deal with transitioning to instate, components, helpers. So we'll keep referring back to this, but I wanna show you this just to help you understand that you're gonna see a lot of files, you're gonna see a lot of folders.

[00:04:08] Each of these has an expressed purpose, and the idea here is to have objects that do something and do it well. And this means the app is highly discretized, there are a lot of objects, each has a single concern. And therefore you know that if I need to massage JSON data I should do it here.

[00:04:36] If I need to deal with transitioning between states I do it here. So don't be intimidated by the size of the source code, is sort of the takeaway here. So this is a great opportunity here to pause for questions if there are any. Cuz we're about to jump into actually how to write the code, yes?

>> Speaker 3: What are your thoughts on using the pod structure instead of, I guess, the original directory structure?
>> Mike: Good question, so pod structure is just, for those who are unfamiliar, it's a different way of structuring your source code. And it would essentially let you, instead of saying in this case, if you have a component which is a JavaScript module that is matched with a template.

[00:05:29] Your JavaScript module would be in the components folder app/components, your template would be in app/templates. And so you sort of end up having to jump around in order to find these two objects that really closely relate to each other. If you set things up in this alternate way called the pod structure, you would sort of have a folder that represents everything that is concerned with a given component.

[00:05:54] And you'd have the JavaScript right there and the template there. It has a lot of promise, there are still a few kinks that we need to work out. And part of the challenge of dealing with maintaining a happy path is that when you try to make things more flexible or provide an alternate route, it's a challenge to make sure that we continue to support this way of doing things.

[00:06:23] And at the same time, make available the new way of doing things. So for example, there are some issues that are more of in add-ons where if you have pods, there are some cases where you can break things. Which is why I'm teaching this today, this is sort of, pretty much guaranteed to work.

[00:06:44] But, if you learn this you could read a blog article about pods and all of the knowledge that we're gonna go over today and tomorrow will carry over quite neatly. It's literally just a difference of where you place certain files, with really no other impact on the app as a whole.

[00:07:07] Does that make sense?
>> Speaker 2: Yep.
>> Mike: Great.
>> Speaker 2: There's a couple more questions coming in. They would like you to explain the services on the slides.
>> Mike: Yes, I'm going to punt on that one, I'll defer that because we have a section today on services. We're going to go deep into that, a very important concept, but we'll dive into it.

>> Speaker 2: Okay, and then are there any other non-documented folders like utils?
>> Mike: Yes, there are more folders than what you're seeing here. And in fact, when you initially create an app, you may not even see all of these folders in your app. But this is sort of the standard place to put things.

[00:07:54] And as we dive in, you'll see that naming of modules and placement in the appropriate folder is very important in Ember. Because it automatically looks for things in certain locations. And you end up saving a lot of time by not having to be explicit and specify that the source code for the component called social info is in a ES6 module in the components folder called social-info.js.

[00:08:25] That's one of those decisions that Ember's trying to remove from the developer because that's not interesting, quite frankly. That has nothing to do with making your app your app, making it unique. It's something that we all have to handle across our apps, and it's in the sort of common area.

>> Speaker 3: You said pod structure can break add-ons. Are you referring to the add-on in particular if you use pod structure in your add-on? Or are you referring to using some add-ons when you have pod structure in your application can cause issues.
>> Mike: The issue I'm aware of is when you consume an add-on that is organized with pod structure.

>> Speaker 3: And you have pod structure, the [INAUDIBLE] right?
>> Mike: Yes, the add-on will pass its tests and work fine, but it has to do with the consumption of it where you can have issues. And this is tracked and odds are by the time this course is published, this issue will have been fixed.

>> Speaker 3: Cuz I thought Stefan was pushing for pods being the defacto.
>> Mike: Stef is pushing for pods.
>> Speaker 4: [LAUGH]
>> Mike: And Stef also acknowledges that there are still things to be worked out. [LAUGH]
>> Speaker 3: All right.
>> Speaker 2: There's also a question on can you switch to the pod structures later?

>> Mike: There, we're going deep on pods here [LAUGH] so you can. I'm not aware of any tool that will automatically switch things over for you. But like I said, when we're talking about pod structure versus not pod structure, it is literally the name of files and their placement in the folder structure.

[00:10:06] So, there is no additional complexity there. If you were to decide to go to the pod structure and rename and replace your files accordingly, things in theory should work just fine.
>> Speaker 3: And I use both.
>> Mike: Yeah.
>> Speaker 3: I use pod structure for all my components, routes, I use standard structure for things like serializers and models and adapters.

[00:10:30] Because I want to see those all together in one chunk so I know what serializers are.
>> Mike: Yep, and to be honest because it's just an issue of file placement in the folder hierarchy, I think that it's much more useful to dive into what these objects do rather than how we structure our folders.

[00:10:52] I mean, that is an ergonomics issue for sure. But more important is knowing the best practices within these different types of objects and modules.
>> Speaker 2: Do you want me to keep going with these questions, or do you wanna wait-
>> Mike: Yeah, just a couple more.,
>> Speaker 2: This is a more kind of general one, is it possible to load parts of a large app?

[00:11:12] For example, if an app has a user side and an admin side, is it possible to load the user's side for users and the admin's side for admins.
>> Mike: Currently no, but in a future version of Ember, and Stefan made me promise to not say it would be a 2.X version.

[00:11:32] But there is a concept called engines and if you've used Rails before, this is exactly what Rails would call this, an engine. It's sort of a sub-application, it would be like if you had a blog that you could just mount in an application. And it has a concept baked into it of a post and a comment and an attachment.

[00:11:57] And it's a lot of functionality including routing and interacting with an API all encapsulated. So there is an effort to do this and it's part of making the story better for huge apps. Like at Yahoo when I was working on their ad platform, 100 people contributing to one project.

[00:12:18] It would be great to have modules or modular app structuel where people could individually deploy things. And you could asynchronously load the admin section only in the case where the user's an admin, and only when they navigate to a URL that is the admin section. So there is awareness of the pain point, there is a plan.

[00:12:42] There is an RFC, like a speck that has been discussed over the past couple months, a lot of lively debate there. And I know for a fact that there are big companies that are sponsoring core team members to develop this feature in the near term.