Hello folks and welcome to the ninth edition of the interview series “I contribute to Ember” , presented by the folks at The Ember Times 
This week we’d like to highlight the work of contributor @pzuraq who talks about his story getting involved with working on native classes and decorators in Ember and why everyone in the community is eager to help make your contribution a real success as well.
How did you get started with using Ember?
I got started [with Ember] as I was working at a small speciality car sales company in the Bay area when I was a student. And I was tasked with building this very large, very grandiose application. It was supposed to cover all these use cases for […] CRMs, it was supposed to manage the content on the website, it was supposed to manage their inventory [and much more], and they thought they could build this project with a single college student on a very, very limited budget. And my manager [being] a person who had lots of experience with the .NET stack and Microsoft back in the day, like 10 years before this, he wanted me to build a .NET app. I started looking into it, and I realised that that was gonna be very hard. NET is not super accessible if you haven’t learned much about the Microsoft stack. [As in] it’s not easy to google: “How do I start a .NET application?”.
So I decided to instead pitch [the project] with a Ruby on Rails backend and a JavaScript frontend. And I debated between Ember and Angular for quite a while, but I went with Ember cause their router was just way better. And this is how I got started using it.
What have you been working on recently?
So the number one thing I’ve been working on for the past almost 2 years now has been native classes in Ember and decorators. Specifically, figuring out how we are going to make classes work with native syntax instead of just trying to replace it. One big thing about the Ember community is we always have a transition path. So now the way we have it set up, classes are fully compatible with each other - both syntaxes. So you can extend using class syntax from classic classes - this is what we’re calling the old class model now - and you can then extend from a native class using classic class syntax. You can go back and forth between the two, so everything works, and you can basically go throughout your codebase find one class that you wanna convert at a time and convert it - with no worries.
So that was a big part of that whole process. And then figuring out decorators, figuring out the various changes to the spec as time goes on. It was actually very interesting trying to get decorators to work on both stage 1 and stage 2 simultaneously, and we managed to make it work. And I’m not sure if it continues to work in the future we may have to have a new breaking release at some point. […]
More recently I’ve been working with Tom, Yehuda, Kris Selden, Robert Jackson and lots of others to finalise the specification for various other features that have been in the works for a very long time. So Glimmer components, tracked properties, and various other small little details like element modifiers and render element modifiers. Mainly I just wrote the Request for Comments (RFCs) and made sure everybody was on the same page. I definitely was not the person who came up with those ideas, but I’ve been involved and loved working with everybody on it. I learned so much in the process, and I’ve also been implementing the changes once they were completed. Although tracked properties were already there, that was Chad, it was behind a feature flag, so I updated a few things and then we just flipped the feature switch.
What made you interested in bringing native class syntax to Ember?
So when I actually started I was […] at Addepar which was the company I was working at [back then], I was tasked with building out our documentation solution for various components, addons, we wanted to write internally. I was looking at the various tools that we could use to make automated API Docs. […]
[In this regard I think] the best tooling requires almost zero effort. It makes doing the right thing very very easy, so the majority of people are encouraged to do it […] - the benefit is worth the cost basically. I don’t feel [with tools] like YUI Doc and older doc style tools that’s true.
So I started looking into the newer generation of documentation tools, especially TS Doc or TypeDoc for TypeScript and ES Doc - which is an interesting project in terms of how it’s being developed. But its goal was really cool: Let’s make a doc generator, that just analyses class syntax, and that adds all the info without having to do any extra work. I thought that was amazing. And I heard from a friend of mine, Chris Thoburn, […] that class syntax actually almost worked in Ember and it just needed a little extra push. So I reached out to Rob Jackson, and I was like: “Hey, I see you got this ember-computed-decorators project and it mostly works, but it doesn’t have service injections, and it doesn’t have a few other things - what else do we need to make classes work?”
And we started talking and working together. We realised it wasn’t that much more work, and it probably was where the Ember Community was wanting to go. Ember CLI TypeScript was starting to become a thing. People, in general, were beginning to move in that direction, and decorators have been moving forward. Very soon after they moved to stage 2, I believe. And so things started to solidify in the native class work and that it was like “Ok, we can do this. We can drop that extra weight and get things settled.”
That’s basically how it all started.
Has your work on native class syntax in Ember been your first significant contribution to the project?
Yes, it has been. I would say this is the first major point where I started really contributing. I did write an RFC for Ember CLI sometime before that, like a year before that, and I had contributed to Ember CLI and Ember in various, small ways before. The RFC didn’t really go anywhere. I don’t even think anyone had the time to review it. Ember CLI was evolving very quickly at that point. […]
It did also start with [the work on the addon] ember-decorators and exploring things with this independent library. So it evolved slowly. It wasn’t like: “Oh ok, you’re gonna do native classes for Ember” at first, it was rather like: “Oh, let’s make ember-decorators better, and then let’s figure out which things in CoreObject need to change.” Very small pieces, one at a time. […] And so that snowball kept growing and growing and growing, And all of a sudden we were doing everything. Figuring out a full plan, and writing a codemod, and now we have Ember Octane.
Do you remember your first contribution to Ember? What was it?
My first contribution was to Ember Data, and it was really early on in Ember Data. Well, I think it was the pre-1.0, maybe the 1.0-rfc release. So I’ve been wanting to be able to save a RecordArray […]. And I created a PR to add that save function to a RecordArray.
My first cut was very plain and straightforward and called save on everything on that array, [and I thought:] “Cool!”. And that failed tests. I tried to rewrite it [and] I had no idea what was going on, I had no idea why Safari, in particular, was failing. So I ended up writing all these major hacks and I remember Yehuda came in and commented, and he was like: “I’m not sure if this is the way we wanna do this.” Then Stefan Penner came out of nowhere figured out what was going and he was like “Ok, you can turn it back to what it was originally.” I felt a little embarrassed as I had no idea what the problem, I still don’t know what the problem was until this day. But he fixed it. And it got in. And then I didn’t contribute to anything for another year or two I think, haha!
Any piece of advice for first-time contributors?
[My advice is:] Basically, just don’t get overwhelmed. Start small and keep focussing on trying to understand the whole problem and the whole system. It can get overwhelming in the Ember codebase, in large codebases in general. I mean I’m sure [the codebases of] React, or Vue are just as overwhelming as that at some level. If you want to contribute to a major project like that though, you can find small things to work on first and then start gaining more knowledge about the system and getting [started working with it]. And slowly begin to understand this is how a particular part of the system works.
It took me 2 or 3 years to read and debug the code here and there […] and to really understand how Ember’s computed properties work for instance. And a few times I went through and really read all the code paths and really tried to understand it, but it’s large. […] Even today I still have to refresh on certain parts when I’m working on it. So It takes time to build up that knowledge to be a very effective contributor like Rob Jackson or Kris Selden who just understand and have all that context. Definitely be patient. Don’t beat yourself up too much for not understanding it all at once because there is a lot going on. Especially in a legacy codebase like Ember where certain parts are like “Oh yeah, we wrote that when we had ES5 and things were a little different.”
The second piece of advice I can give: Ask for help and talk to the Core team members, talk to maintainers, talk to people who are working on the project actively. They almost always want to help universally. Often they don’t have much time. Like myself, I don’t have much time these days. I’m just constantly working on Octane or decorators or native classes, but I always try to make time to respond to questions and to give people context and in general I love it when people reach out. I’m trying to help them and level them up. It’s really just a matter of balancing: what I have to do for work, what I have to do for open-source, [what I have to do] for Ember and also that. But if I don’t respond in one day or two days, or Rob or Stef doesn’t, they may just be busy. And in general, as I said, I always love people who are able and want to contribute.
Chris Garrett, also known as @pzuraq, is a Senior Software Engineer at Linkedin and a contributor to Ember. You can also find him on Twitter, Github and Linkedin.