Transcript

In our last episode, we showed this piece of code. It's a link-to helper, and then it has this thing in parentheses, that I told you was a subexpression. Today, we're going to be exploring more of what it means to be a subexpression.

Subexpressions Theory

A subexpression is basically a handlebars helper that's used within a mustache, usually either another handlebars helper or a component. The subexpression collapses down into another argument. So outer expression here takes two arguments, one of which is the result of the subexpression.

So once again, the outer expression can be a component, a handlebars helper, or any mustache that takes an argument. Meanwhile, the subexpression has to be a handlebars helper. Let's look at an example.

This is the handlebars helper that we've created called es-equal (Ember Screencast Equal). I'm doing the ES because you have to have a dash to use Ember CLI handlebars helpers with their defaults. As we can see, it takes just two arguments and checks if they're equal. Then down here, we can use it here. Rather than defining a property called hatIsBlue, in the component or controller, we just compose it in the handlebars.

Here are two other simple examples, "es-and" and "es-not." How you use them is pretty self-explanatory. Let's look at them both together. Here, we have es-and with selected sort with es-not is ascending. es-not is ascending collapses down to a boolean, which is then fed as the second argument to es-and so you can compose subexpressions as much as you want. Bonus points to the first person who recreates Lisp in subexpressions.

Apply to our Tables example

That's the theory. Let's apply it to the example app that we've been using. We'll start by adding the es-not and the es-and helpers, just like we saw them before. We're going to use them to replace the upArrowHighlighted property and the downArrowHighlighted property. You can see that the upArrowHighlighted property is when both isSelectedSort and isAscending are true. We use es-and for isSelectedSort and isAscending. downArrowHighlighted is very similar, except we want it to only accept if isAscending is false. With those in place, we can now remove these two properties from the component.

Is it a good idea to replace properties on the component with nested subexpressions in handlebars? That's really up to the situation. In this case, it's a toss-up because both of them are fairly clear because we named it