 the perfect computed property or how I learned to stop worrying and use a bubble transform in an amber add-on with a computed property macro based on template strings. So now Peter Seller does a much better German accent than I have, unfortunately, he's still the man. So who am I? As I said, my name is Serena and I'm a product engineer at Intercom. That's my Twitter handle. I'm always looking out for followers. And this cog is actually a collaboration between me and my colleague Gavin Joyce, who many of you know already and who's an avid community, who does a lot of community work with amber. So Intercom is a customer communication platform and it's actually quite a large amber application. And this graph actually shows relatively well how our production code grew in the last two years alone. So here you see the blue lines are the lines of JavaScript, red the lines of handlebars and then green JavaScript and handlebar and it goes up and up and up. And the problem with large or increasing code is increasing complexity and the application and increased application payload and it slows us down as engineers as well. There's a big cognitive load for new engineers to come in and learn code or read over the code. So at the beginning of this year, we actually made an explicit effort to bring down the number of lines of code. And then not actually by just going into our code and removing lines of code, we actually shipped quite a lot. We actually even shipped a new feature, but by being really frugal with how we use code. And one of the things we use a lot is computed property macros. So amber has a lot of computed property macros or has its own set of computer property macros which you see here, just a subset of them, we probably all use amber not, amber and we also built our own set of computed property macros. The advantage of them is to get rid actually of multi-line computer properties. So I show you an example here now, so these are some of our computer property set of computer properties like half, for example, would have a computer property value. Computer tannery is a tannery operator for computer properties and the advantage of having our own computer set of computer property macros is to get rid of some of the duplication of code. I show you an example in a moment that makes it better understandable, but that's quite a lot actually. I practice only with Gavin, he says the occurrence of percentage and add with the string template. So in this case... Can we do a quick bit of running... It was really useful, right? It was that useful actually that we wrote our own computed, our own computed property macros, which we called computed format, that's exactly the same thing like string format just with computed property. So you here see high the percentage, so percentage, add percentage, first name, last name, first name, last name are computed properties. And it actually uses ember string format under the hood. And the advantage is that it actually is a one-liner, a one-line computed property macro compared to when you see usually you have this canonical example, first name, last name, and the duplication of the two computed properties here. So it's much easier for, for example, new engineers to reason about what the string means, what the code means, and the cognitive load is a little bit decreased on engineers. But unfortunately, we have this problem, ember string format got deprecated in ember too, right? So we have to rewrite our computed format. So what do we do? So the first approach of the first proposal we did was, in January, Gavin actually posted on ember CPM, this is the computed property macros for ember, an idea for a computed property macro, a new idea. And what does it look like? So the first idea was be, okay, let's use something similar, sorry, so string format was replaced by ES 2015 template strings. So let's use something similar to this. So here you see, for example, the template, high first name, last name, using ES 2015 syntax like, sorry, syntax like, sorry guys. I reboot my brain. So then Robert Jackson actually posted a question on that proposal saying, why are we not using tag template strings actually? Why are we not using tag template strings? Because it has been done. So there is actually an add-on called html bars pre-compiler add-on, which does exactly that. They use tag template strings. So this add-on allows you to pre-compile inline html bars. And so for example, this string HBS, high name, this tag template gets extracted into this huge code, or this bigger code here. So okay, next idea. Let's use tag template, the literal template, high first name, last name, cool, problem. We can't do it that way because we're getting JS hint errors. The problem is that the variable parts first name and last name can't be resolved at modular runtime. So that's not an approach, we unfortunately can't take this. So we have to go back to the drawing board and go back to our original idea with using plain strings when we actually resolve the variable parts at runtime. So okay, this was our first proposal. We came back to it. We think, okay, this is probably the best way to do. So we have this idea of using this one-line computed property macro and transforming this at runtime into a computed property function. So you see here, the variable parts would be then resolved properly in this function. The way we actually realize this is we built an amber add-on, and this amber add-on uses or imports a template parser, which is a node module. And I will talk about them now in more detail so that you understand what we actually did there. So the template string parser is actually the one which does the proper work here. So before you had the string with dynamic and static parts, so name and age are the dynamic parts, the rest are static parts, and this would return then, so this would get as input the string and would return the function, this computed property function with all the variable parts resolved. I had a look at EmberConf this year, James Kyle did an amazing talk about the super tiny compiler. Has anybody seen it, guys? It's really, really good. It's a lovely talk. I really highly recommend you looking at it. And we did something similar. James's compiler is actually more complex than ours. Ours is super simple, and I'll show you now very quickly how we do it. So as I said, we have to parse out the static and the dynamic parts, right? Sounds easy. So what we do is we walk through the string character by character, and we're pretty dumb about it. So what we do is, okay, we start up, hi, this is probably a static part, because we haven't seen any indication that this is a dynamic property, because a dynamic property is, or sorry, a dynamic part is indicated by the dollar open curly braces. So we're walking through character by character until we're finding that until the next character will be a dollar, and the next character after this is an open curly braces, and this is probably then from the start index to this point is then a literal. So now we're in a different mode. We are reading in a dynamic part. We're reading this in until we're finding the end of a dynamic part, the end of the dynamic part indicated by close curly braces. So again, quite stupid, that parser goes on until it finds this close curly braces, and this is a dynamic part. So this is the first one was a literal, the next one will be popped onto this deck as a proper team. So the next part here you see comma, and then the space UR, again a literal part, and the next part here, this is a dynamic part. So these are the actual, so we have two static parts and two dynamic parts, so the parser then can just literally concatenate them together to form this property function you saw before. The amber add-on will import that parser as a dependency, and I show you now on this code what we did actually here. So we have a couple of things that are important. So the first step is we actually have to find out what's the imported function, what's the name of the imported function. So that's the first step which it tries to find. So okay, in this case import template string, so template string is the name of the imported function. We then find where actually in the code it is used. So in this case, the third computer property greeting uses that function, and we're just reading out the string part, the template part of this function, which is this high dollar name, UR dollar H, and this will be given to the parser as an input, and the parser returns the function you've previously seen. So we're using bubble transformations in this amber add-on to actually, to actually replace the abstract syntax tree of the code with the newly returned function. So in this case, the computer property greeting, or the part greeting, will be replaced by this new function, the return function from the parser, which is the canonical example as you see. So before we have a one-liner here, template string, afterwards, canonical example as we all know. And the really nice part about this is that at compile time, you actually don't have to reason about much code, because it's still a one-liner, but at runtime, we don't have much runtime abstraction, so it's just literally like the string concatenation. There's not much to it, so I'm pretty sure you're all excited about the demo. I am, so one second, sorry, I make this a bit bigger. So we actually open source both the parser and the add-on, and I just show you quickly, sorry guys, I have to click through, I will give you the URL again, because we're always interested in new PRs and extending this. So you see here the example, we have two computer properties, first and last name, we have here as an example as a comparison the two computer properties using the canonical examples, canonical computer property functions, but then we have here the two full name two and creating two which use our computer, the new computer property macro, our new written one. And I would say, I think I like the two last lines better, I don't know about you, but I think it's much easier to reason about one-liners than about the two or three-liners. So I run this here, and you see here it works exactly the same way like if we see Ember camp, so the code is not, we didn't destroy anything, and the interesting part is if I go into the source code and I show you now how it looks, I don't know whether you can fully see it, but it's pretty much transformed into the same code like the canonical examples would be. So just anything, we haven't destroyed any functionality here, and if I go back now, sorry guys. So you probably all ask yourself, how do I use it, because I hope you all want to use it and are excited about it, you just install it as an Ember add-on, that's the nice part about Ember that gives us all these tools and tool sets to do it really easily and then you just use it and hopefully do loads of one-liners and get rid of cognitive load for your engineers, and also like you make me very happy if you would help us contribute and bring ideas like there's probably loads of things we can still do with it. So with this nice gentleman at the end, what did we do? So Ember string format was deprecated and we used it in our computer property macro, and we needed to rewrite it. We had a lot of ideas and approaches, but finally we went with the basic plain strings where we pass out the variable parts and transform them using bubble transformations at runtime, and we wrote it as an Ember add-on, which was actually quite quick to do. Thank you very much guys for your time.