Published on Mar 28, 2015
You can put handlebars helpers inside your handlebars helpers. Handlebarception!
Learn how and when to use subexpressions, as well as how to compose them and use them to replace properties on the controller or component.
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.
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
- Sorting Tables with SortableMixin
- Sort Arrows (and refactoring into a component)
- highlight selected sort options
- query params
- Handlebars Subexpressions
- Client-side Pagination Part 1-Basics
- Client-side Pagination Part 2-Previous/Next Page Buttons, Change Page Size
- Metaprogramming Magic with arrays and the ember get helper addon
- Dynamic Toggling of Tables
- Rearranging Table Columns
- Handlebars Subexpressions
- Sorting in Ember 2.0 (Replacing SortableMixin)