Ember 2.x Ember 2.x

Creating an Ember Add-on

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

Ember add-ons are components that are external to the application. Mike demonstrates how to create an add-on and explains how the add-on and it’s dependencies are included in an application.

Get Unlimited Access Now

Transcript from the "Creating an Ember Add-on" Lesson

>> [MUSIC]

>> Mike North: Last piece of course I'm going to show you how to create and Ember add-on and how to consume it in an app. We're gonna keep it really basic here. I just want you guys to understand how to create it, how to have things remain internal to the add-on versus exposing them to the app, and also some little testing in new answers that you should be aware of.

[00:00:28] So the way you start out a new Ember add-on is, ember addon, and we'll call it fem for front end masters. So similarly, just like Ember new, we've got a blueprint here. We're creating a bunch of stuff, bunch of test working right off the bat.
>> Mike North: So what we're gonna see is, and you can already see a little bit, there's an app and an addon folder.

[00:01:02] An important distinction to make between those is that the addon folder, those modules will be name spaced to whatever your addon name space is. Everything in the app folder will be merged into your consuming app. And so, here's why that's important. Components and helpers register themselves and make themselves available if they're in the correct name space.

[00:01:27] So it's important to make sure not only is your addon folder containing the component as a whole, but you also sort of pass it through to the app folder and we'll see how that works. Just to make sure it's made available to everything that's consuming it. So you're gonna see in addition to those two trees of files which we'll both have our respective components folder, our templates folder.

[00:01:53] It's sort of the same structure as our app folder. There's a third one and that is used for testing. So there's sort of a dummy app that's used both for acceptance testing your Ember add-on, as well as people often use this as sort of the demo page. They'll push it off to GitHub pages, and it'll be part of the documentation that proves it's actually working.

[00:02:19] So, we'll go to fem, and if we open this up and bring it into our workspace.
>> Mike North: Fantastic, so app folder, which is empty right now, addon folder, which is empty right now. But these, once we start creating a couple of things, and you'll see that Ember CLI is still doing a lot of work for us.

[00:02:47] Things will sort of start to mirror each other. Additionally, in the tests folder you've got this dummy folder here and that looks like an app. This is what you'll startup when you hit Ember S. You'll serve up your dummy app which will already have consumed your add-on. It's a way to test to make sure that everything works as expected, as part of the development process.

[00:03:16] So you can TDD in your add-on and it sort of has a simple app for you to work with. So, kill this URL. We're not serving it, we'll start it up.
>> Mike North: All right, it's serving, so I have some breakpoints left over. Welcome to Ember, and I'm gonna prove that this is the dummy app being served.

[00:03:51] I'll change this.
>> Mike North: And it will refresh. So dummy app but if we look at the modules that are available, you'll see that, well we should create something first but you'll see that all of the add-on code becomes available. So let's build a component. Ember g component and we'll call it, because naming things is hard.

[00:04:21] So this is doing more work. This is doing more work than creating a component in an app. You can see that we've created an add-on component and an app component file. So if we go back here and we look at social-info, there's the component as we expect and here's its template.

[00:04:45] But also we have this sort of pass through. So this is in the app tree. Effectively, what this is doing, it's importing the ESX module from our namespace and bringing it into the app namespace by just exporting again. This is where you could potentially extend things or typically you wanna keep this very small.

[00:05:13] But a use case for messing with this might be if you rename social info and you wanna actually export it twice as social info or social stuff. And maybe you wanna deprecate one of them. This would be the place to do that, right. So you just have your core component but through one path you can deprecate or you can throw a warning or something and then make it available through the other.

[00:05:39] But typically, you're just gonna wanna leave this alone. So we'll just add something cuz we've already gone through components here.
>> Mike North: I'll just make it boring. [LAUGH] And bring it into our application.hps.
>> Mike North: Could not find module. Templates social-info.
>> Mike North: Interesting.
>> Mike North: I'm not sure what's going on there.

>> Mike North: Components.
>> Mike North: I'm gonna try bumping up the Ember version here just for kicks.
>> Mike North: I get it, okay. [LAUGH] So, one thing to be aware of is that add-ons can do a bunch of different things, this is actually good that I had this, add-ons can do a bunch of different things.

[00:07:24] You can have components available that you are exposing to the consuming app like what we are setting out to do here. But you can have add-ons like Ember CLSS that you know add a step to the asset pipeline to transform additional assets. So by default there may not necessarily be something visual here.

[00:07:47] So what we need to do is make HTML bars available as a dependency instead of a dev dependency to ensure that we can actually build templates at build time in consuming apps, not just in the add-on.
>> Mike North: Hopefully this works now.
>> Mike North: Never mind, let's switch it over but it looks like a better result.

>> Mike North: Fantastic, so that was the problem, ember-cli-html-bars has to be a dependency.
>> Speaker 2: Docs mention that?
>> Mike North: I hope so. If they don't I'll PR it in shortly. [LAUGH] All right, so we have a component here and the point is not to go through the component lesson again, but to explain how this would work in a consuming app.

[00:08:50] So I wanna show you the ES6 modules that are available here so we can see some important differences. If we look at Sources > assets. All right, so we've got fem and we've got a component here. And this is actually the component itself. So I want you to note that this is the name of the module.

[00:09:13] So if we were to bring this into our app, this would not be picked up as a component. And the reason is our app is looking for github-ui/components/something. If we look at dummy components, this is the pass through. And in this case, it's been built for the dummy app and massaged a little bit.

[00:09:40] But I want you to see that effectively, I want to get rid of this here, effectively, this is where this pass through happens. And this is why it's so important to have, in your app folder, those sort of really short modules that import and then just immediately export.

[00:09:57] That is your ability to control what's private to your add-on and what's exposed to the app. Very important for helpers, very important for initializers which we didn't get into but that's how you customize the way the app starts up. Initializers simply by being in the Initializers folder will be called in the order that they register themselves.

[00:10:22] And so that's another one that like where there is sensitivity to being in the app name space of whatever is consuming.