The Story of How Our AngularConnect Talk Came To Be

When you watch a conference talk you see a final product. Often times, the talk is very polished and it seems like the speaker has total command of the subject. Things like Live Coding on-stage, usage of humor, and even acting parts of the talk make the talk a memorable experience for the audience. But what does it look behind the scenes? How are such talks are prepared? These stories are almost never told.

In this blog post, I am going to share with you the story behind such talk, “Climbing Up Injector Trees”. This talk is a Duet talk: Kapunahele Wong and I presented it during AngularConnect, exploring the behavior of Angular’s Dependency Injection in various scenarios. We used a mixture of live-coding and slides to show and explain various aspect of Angular’s DI resolution algorithm.

Our AngularConnect talk: Climbing up Injector Trees

Where did the talk idea come from? How was it born?

Choosing a Topic, Submitting a Talk

Kapunahele and I met in ngAtlanta, back in February. We met again during ng-conf 2018, and joined the Angular team for a dinner (thanks Misko Hevery for making that happen!). This was a memorable dinner, as Shai Reznik was also a part of the group:

A few minutes later, everyone in the group got up and started dancing Salsa. The Angular community is so much fun!

Kapunahele and I got an opportunity to speak during and after the dinner and I recognized she was very passionate both about Angular and teaching developers, just like me. We started chatting on Twitter:

About a week later we talked again and discussed some initial ideas:

We scheduled a video call a few days later, where we discussed the ideas we had for the talk. We ended up narrowing it down to two topics: Injector Trees (suggested by Kapunahele) and How JavaScript’s Garbage Collection Works (my idea).

We decided to meet again the next week, and to have each of us write a short abstract for the other person’s talk idea. That would make the process more interesting, and also make sure we are on the same page. The next week we went on another call, where we polished the talk abstracts and submitted them.

When you submit a talk to AngularConnect, they ask you to explain why the topic is important. I decided to include both talks we submitted, so you also get to see what wasn’t picked up by the conference:

Climbing Up Injector Trees

Dependency Injection is at the heart of Angular. We don’t even think about it too much — we ask for a dependency, we get it. However, once our app grows and we have multiple NgModules, lazy loading and use third party components, things start to get more complex. In this session, you will learn about ElementInjector and ModuleInjector, how they work together, and the two-pass dependency resolution process. Did we mention it is going to be fun? 💉🌲

How is your talk relevant to this audience?
Injector Trees are hidden deep inside the guts of Angular. They are an essential part of the framework, yet, they are often overlooked even by experienced developers. Our talk aims to change that by bringing Injector Trees to the center of attention and explaining the way they work in a fun, memorable way.

Take Out the Rubbish

For most of us, garbage collection just happens. But did you know we can make poor choices that lead to memory leaks and degraded performance? In this session, you’ll learn how the garbage collector works and how you can regain control of memory management. Performance in, garbage out. No leaks allowed!

How is your talk relevant to this audience?
As developers, we are always striving to build faster, smaller apps. However, we sometimes face issues that we may not even know are related to garbage collection. Like a black box, the garbage collector performs its work under the hood. As result, most of us can get by without understanding it. Nonetheless, when we examine its inner workings, we can leverage that knowledge to dramatically improve our app performance.

In addition to these talks, I also submitted a talk about Abstract Syntax Trees together with Craig Spence (seems like I got something with trees…).

A Happy Mail, Time To Work!

Life went on. The next month was packed with conferences for me (AngularUp, BSidesTLV, GeekTime DevFest, as well as some meetups), so I didn’t spend any time thinking about the above submissions nor looking into these topics. Until one day the following email landed in my inbox:

Hooray! One of our talks was accepted! 🎉🎊🎉

Well, but I didn’t even have the slightest idea about how Angular’s Injector Trees work. I have never looked into the subject, and it seems that Kapunahele felt pretty much the same:

Sometimes you secretly wish they hadn’t picked up your talk

So we had to start working! We did have some documentation draft Kapunahele wrote a few months before, so we used it as a starting point, and set a meeting to brain storm about our talk. Due to some personal circumstances, we only met about a month later, at August 16 and started planning. We still had 2 and half months until the conference, so we took that meeting lightly.

After about a one-hour discussion we came up with some ideas for elements we can include in our talk:

1. Sloth (for Lazy loading)
2. Cats (because they like to climb trees, duh!)
3. Audience involvement — some kind of quiz

Eventually, the Sloth turned into a GIF in one slide, the cats didn’t make it to the talk, and we actually created a quiz but later decided to ditch it. More on that soon.

Standing on the Shoulders of Giants

We created a shared document for planning the talk and started collecting relevant articles and documentation:

We spent some time reading these documents and extracting many bits of information we found useful. Two weeks later, on August 30, we met again and summarized what we have learned up to that point. Kapunahele created a couple of diagrams that outlined the way that Injector Trees were searched by Angular:

These three diagrams are just three different approaches of showing how Angular looks for a dependency in the ElementInjector and then the ModuleInjector trees. Eventually we didn’t use any of these diagrams — rather a much simplified version that matched the examples we live-coded on stage. But they helped us wrapping our heads around the subject.

Prototyping Some Code 💻

At that point, I started writing some code to test our understanding of the concepts and to verify they worked the way we thought they did. I started with prototyping some quick app on StackBlitz, which would later become the basis for our first demo.

We also started planing the outline for the talk itself. This is what it looked like:

Role Play — Intro

We can start with a quick role play, where Uri asks Kapunahele why his Component gets a different implementation of some service than he expects. Then Kapunahele says it could be related to the dependency being defined at the Element Injector level, at some level above Uri’s element, and Uri is like: Huh? Element Injector? What’s that?
Kapunahele then tells uri a story about a cat:

Visualizing the Lookup Algorithm — The Story
Two trees: one represents Elements, one NgModules

Cat searches the trees for food (its dependency), and has a preference for the Elements tree (why?) so it searches there first. If it doesn’t find there, it falls back to the Module tree.

We can use this story to explain the algorithm in a fun and memorable way.

We then do a few code samples using the cat/tree metaphor — perhaps we can even role-play them / get the audience involved?

Start with Module / Service / Component (that everyone already knows), then move on to defining a dependency on one of the component and introduce the Element Tree.

As you can see in the final talk, the cat didn’t make it, but we did stick with the overall structure we outlined.

We met again two weeks later, and tried to came up with the our key takeaway:

There are two trees. ModuleInjector and the ElementInjector — The way Angular searches through them.

That was what we wanted to teach people who attend our talk. Eventually we also had another takeaway, which is showing the audience how to quickly experiment with various features of Angular using StackBlitz, just like we did when we prepared the talk.

We also started looking into @Host, @Self and @Optional, and I used BigTSQuery to look for how people use them in the wild, but we ended up removing that part as we already had enough content for one talk.

The next week, Kapunahele wrote a quick demo to experiment with the ModuleInjector tree (and also content projection). If you look into these initial code samples, you will find them much more complex than the samples we ended up using in our talk. Simplifying the samples was where we spent most of the next month.

The next month was pretty busy for me — I spent most of my free time blogging as part of my one-blog-post-a-day challenge, got married in spoke in several conferences. We did have a short meeting on October 4th, were we went over the code samples Kapunahele created and I asked her to write down any questions she has while researching the subject, and she also created some more diagrams (which again, we didn’t end up using…):

Our examples ended up being much simpler, so we didn’t need these diagrams to explain them

Let There Be Slides!

It wasn’t until October 20, less than three weeks before the actual talk, when things shifted to high gear. We met again and planned the final outline for the slides, which looked like:

1. Introduction (background story or so)
2. Show the “standard” way of working with services (provide in modules)
3. Show that we can override a service inside a component
4. It also affects its child components
5. How does Transclusion affect the resolution?
6. How do lazy-loaded modules play together with different provider implementations. (There are two different implementations depending on how you inject it — in the lazy module or in the component). Compare lazy vs standard.
7. Apply this to the Use Case (if we have one)
8. (Kapunahele — @Host @Self — -> make that slide — mention quickly and check them out if you want to dive deeper)

At that point, we stopped working on the shared document, and started working on the actual slides. We met again on October 23, when we started nailing down the specifics of the talk, such as planning how we will enter the stage:

Kapunahele goes on stage, looking for Uri, asking the audience
After a few moments she spots Uri at the corner of the room, asking if he forgot about the talk they had
Uri says he has been busy trying to solve a bug and he has issues with DI, and he didn’t look at the time
Kapunahele invites Uri to stage to look at this together
Uri goes on stage, explains that he doesn’t seem to get how DI works behind the scenes and he’s confused and frustrated
Kapunahele offers to explain how DI really works in Angular
We introduce ourselves, talk starts…

In addition, I shared some of what we learned in our research so far in a blog post: “Transclusion, Injection and Procrastination”. This helped us summarize our research, and also get some feedback from the community just before the talk. For instance, Lars Gyrup Brink Nielsen pointed out that Transclusion is now called Content Projection, so we updated our slides accordingly.

Live Coding, Shall We?

At that point, I suggested to Kapunahele that we will live-code the demos on stage. As she took the “instructor” role in our presentation, she would have to do most of the live coding. She told me that she fears this was not going to work out — as she tends to get confused and make silly mistakes even when there is a single person watching over her shoulder, let alone a room for of people.

Nevertheless, we decided to at least give it a chance. The following week was quiet intense — we met 3 more times, spending several hours each time doing dry-runs while iterating on the slides, simplifying the diagrams, crafting the live-demos we were going to code, and creating a GitHub repo with a different branch for each of the demos we were planning to show.

At first, Kapunahele did make a lot of silly mistakes, just as she thought she would, but after some practice (and preparing some code snippets), she started feeling more comfortable and as you can see in the final talk, she rocked it.

I also started working on the a small quiz app using Firebase and Angular— we wanted to let the audience vote for each for the demos we show, to tell us what they think the outcome would be, just before showing the actual result. We only had one week to go!

Final Practice and the actual Conference

Ariella and I traveled to London a week before the conference, so I took some time off working on the talk. Kapunahele kept on improving the slides and practicing, and we finally met the night before the conference.

We did our first face-to-face dry run, and timed it 36 minutes. Not too bad considering we also updated the slides and took some notes in the process. We also decided to ditch the quiz, as it seemed like we don’t have the time for it.

We did another dry run the next day, and a final one just before going up on stage, which we timed 32 minutes. Finally, we felt we were ready for the real thing!

“A quick show of hands” — no need for a quiz app

So What Does It Take to Create a Talk?

We met 2 times for coming up with talk ideas, polishing them and submitting them. We met 9 more times online to work on the actual talk, and then did 3 dry-runs in person just before the final talk date. I don’t have the exact figure, but I believe we spent about 20 hours in total working together on the talk, in addition to some hours we spent individually researching between our sessions.

About half of the time was spent on learning the subject, researching it and experimenting, and the other half on making the slides and practicing.

We ended up with a 24-page document containing a mixture of research results, ideas, and random thoughts we had while preparing for the talk. We moved from working on the research document to working on the actual slides about two weeks before the conference — that is when our research was done and we felt we were ready to formulate it into a talk.

Some of the things we worked on, such as the quiz or the part about @Host didn’t make it into the final talk. This is something usual — I always find myself preparing more content than I actually use/present in my talk.
What makes your talk great is not the content you put it, rather the parts that you decide to leave out.

I’m very happy with the result, and it seems like other people are also:

It’s Your Turn Now!

So here it is, the full story behind our AngularConnect talk. Did you too give a talk at a conference? How did you prepare? What did your process look like? I’d love to read your story too. And if you haven’t given a talk yet, now is a good time to start!