Published on Apr 06, 2016
When you create an addon, a dummy app is created in your tests folder. How can you run the dummy app, and how can it help you catch problems in your addon?
In the addon folder you can serve the dummy app:
cd blink-tag ember s
To generate files using a blueprint within the dummy app, add
ember g component new-tag --dummy
Hey everyone. Today we’re going to be continuing our series on developing your own addon. The subject we’ll be covering is using the dummy app. So here we have our dummy folder, and that’s within the tests folder. And it’s in here because it’s used for both manual testing which we’ll show you this episode, and automated testing which we’ll show you next episode.
So within our app folder within dummy, it looks just like a normal app. And then we have our config and public folders, which are pretty similar to what they are in normal apps. And you’ll notice that’s all we have. That’s because the
package.json that applied to this are in the root of the addon.
So before we go farther, let’s get to one of the reasons why we need a dummy app and why we can’t just use it on our other apps.
So this is one of our other apps that’s using the blinktag addon, and it’s working just as we had hoped it would be. Now let’s go ahead and shut down the app we’ve been using and we’ll start up the dummy app. So this is in the root of the blinktag addon folder, and we’re typing in
ember s, and that will serve the dummy app on
localhost:4200, just as if it was a normal app. So we’ll do this, and this is in our basic dummy app, just ‘Welcome to Ember’.
We’ll go ahead and go in here in our templates in our application, and replace this... well, not replace it. We’ll put in a
blink-tag. So you’ll notice we already have our
blink-tag in here. It’s automatically available. But it doesn’t do quite what we would expect, and this is because there’s a secret dependency that we already had in our other app that we’re using to test this on. But it won’t be in most apps and it’s not in our dummy app. So it’s a good thing we tested it like this so we could catch it.
So I’ll go ahead and quickly walk you through how I figured out where the problem was. So I went in here and I put a
log statement here in every interval to make sure that it was still doing this. And then I came back and I checked and I saw that yes indeed, it is going through the interval. And so what’s the issue? Well then I saw that we’re turning the property
show on and off, but we haven’t defined
invisible anywhere. And this took me a little bit of searching to find, but it ended up being defined within the
bootstrap addon that we’d had in our other app. And so if you don’t have bootstrap installed, then blinktag won’t install either. So that was a hidden dependency. And obviously we don’t want to include all of bootstrap just to make blinktag work.
So here we have two options. The first is to go into the styles folder of our dummy app and create something for the class
invisible. And here we’ll just have
display: none. And with that... Hey! Now it’s working. But there is a downside to this in that it still won’t work if the consuming app doesn’t either have something like this, or it doesn’t have bootstrap. So we’ll go ahead and make this available in the consuming app. So we’ll copy that, we’ll cut that, and we’ll create a new folder here,
styles, in our
addon folder. And then we’ll create a new file called
addon.css. And we’re calling it that instead of
app.css so that it doesn’t conflict.
Alright, and with that... well, as you can see, it isn’t working quite yet. We’ll have to go and stop and restart our server, and it should pick it up. Of course with a setup like this, we can run into namespacing issues.
.invisible is a pretty common class. So that we’re making sure we’re not stomping over something else, let’s go ahead and call it
blinktag--invisible. And then here we’ll do the same here. And now we have something that works and is unlikely to overwrite or be overridden by something in a consuming app.
So that three-minute interlude is an example of the type of problem that you may uncover by setting up a dummy app, and the type of thing that you may have to work through. So that’s already one benefit, is we caught something and fixed it.
For more complex addons, we may have a thing where we test every single part, and whereas over a consuming app, a consuming app may not consume every single part, or it may have them scattered all over the app. In a dummy app we can make it so that it’s all put together in one place, although here it happens to be just one tag.
So I mentioned before that we have
package.json which are used for the dummy app.
ember-cli-build as far as I know is used just like it is in other apps.
package.json is a little bit different in that... well first, the version number here is the version of the addon, but then the
devDependencies are just for the dummy app. The regular
dependencies hash that are not
dev are a little different because these can be carried over into consuming apps.
So there are times when you may want to copy something over from here from the
devDependencies to the plain dependencies hash, if you want it to be able to be used in a consuming app. One common example of this is
ember-cli-htmlbars, which if you have a template you want to copy over, but we don’t have a template in this addon, so you won’t need it. But that is one of the more common ones.
Finally, one more thing to note when you’re working with dummy apps is to generate a blueprint. To generate something within the dummy app, you just add
--dummy, and that’ll put it in
tests/dummy/app instead of in the app.
So this has been a long one, I know, but hopefully it’s helped you understand everything that’s within your dummy app and how you can use that to help make your addons better. I hope to see you in the next episode where we talk about how we can use the dummy app to help run tests in your addon. See you then.