Transcript

In Episode 23, I showed you this piece of code.

It’s a link-to helper, and then it has this argument in parenthesis, and I told you that was a subexpression. Today we’re going to be exploring more about what subexpressions are, and how you can use them and create them on your own.

A subexpression is a handlebars helper that’s used within a mustache, usually another handlebars helper or an ember component. The subexpression it collapses down into a value, and so the result of the subexpression ends up being an argument for outer-expression. So outer-expression takes two arguments, this first argument that’s given directly, and then the result of the subexpression.

So an outer expression, it can be a component, a handlebars helper, or any type of mustache that takes an argument. The subexpression has to be a handlebars helper.

So let’s look at an example.

Here, we’ve created a function and a helper called es-equal. It takes two arguments and then it returns a boolean depending on whether they’re equal or not. Then we can use it down here, comparing the hatColor and the string blue. If we weren’t using handlebars subexpressions, then within the component or controller where this template lives, we would have to create a method called hat is blue, and use that here, in place of the es-equal. Then if we want to check whether the hatColor was red, we would have to create a separate method and so on for if we wanted to check whether a coat color was blue.

Here are two other simple examples, es-and and es-not.

What they do is pretty self-explanatory. And by the way, the reason we have es as a prepend is because if you want ember.cli to automatically detect these and use them, you have to have a dash somewhere in the name. And es is just a prefix we’ve added to ember screencast helpers.

Alright, now let’s see these in action.

So here we’re using both of them in the same handlebars expression. So we’re using es-not to reverse isAscending, and then we’re using es-and to say if is the selected the sort, and it’s not ascending, so not ascending, the result of the es-not, then we’ll show the highlight up arrow. Otherwise, we will not show the highlight up arrow.

You may have noticed that here we have a subexpression nested in another subexpression, and you may be wondering, how deep can that go. The answer is, as deep as you want. I’m just waiting for someone to recreate Lisp subexpressions.

So that’s the theory. Let’s apply it to an example app. We’ll start by adding the es-not and the es-and helpers to our code, just like we showed you before.

We’re going to use them to replace the upArrowHighlighted property and the downArrowHighlighted property.

We can see that the upArrowHighlighted property is true when both isSelectedSort and isAscending are true,

so we’re going to use our es-and subexpression and have as the arguments isSelectedSort and isAscending.

downArrowHighlighted is very similar except we only want it to accept if isAscending is false.

And with those in place, we can now remove these two properties from the component.

So is it a good idea to replace properties that are on the component with nested subexpressions?

In this case, it looks good either way. It saves us a little bit of code to use nested subexpressions but both of them are fairly readable. In some cases like ‘hat is blue’, it’s just silly to have a method on the component, whereas in other cases, the nested subexpressions may become so deep that it’s better to have the logic on the component, rather than having the nested subexpressions.

So in this video we learned about how to create and use subexpressions, how to compose them logically so that we can combine them and replace different methods on the component with them.

In Episode 25, we’ll talk about how to use option hashes in your subexpressions, like this,

and we’ll also talk about some artificial limits that ember places on your handlebars code. I’ll see you then.