In Ember, actions have always been kind of tricky to deal with. The recent introduction of closure actions, although being more powerful, made it harder for the layman to understand. As a result I was still using the old sendAction() way of triggering actions. Then I read this very good article by Sam Selikoff which clarified lots of things. If you haven’t read the article yet, I highly recommend you to do so now.

Although Sam presents many ways you can handle actions, he doesn’t really tell us what’s the best way. Ember’s conventions over configuration paradigm makes creating apps a breeze because we don’t have to reinvent the wheel and instead apply proven patterns to solve common problems. Actions are one of those things that everyone uses, but for some reason I couldn’t find any strong conventions to help me along the way. Every-time I created a new component which sent actions, I always come back to the same question:

How do I name this action?

And while you might think it’s not worth spending much time thinking about it, good naming will impact how you structure your code, help your team communicate, and improve maintainability.

There are only two hard things in Computer Science: cache invalidation and naming things — Phil Karlton

And it doesn’t look like I am the only one in that situation. After a quick look at the add-on landscape, I realized that everyone had a different way to handle actions. As a result, I came up with a set of conventions (or at least, best practices) that I was able to successfully implement on relatively large codebases.