Great article! I like how it takes something such as what type of action to use which would look arbitrary to an uninformed person and exposes the relatively simple logic path people use to land on the solution or correct tool for the job.

Another subtle point of confusion and split decision in the community I have seen is about the use of helpers vs computed properties. Perhaps someone will write another follow up article on this one.

Specifically from addons like this:

Which allow all these great functional programming style concepts within the template. Such as their example:
`{{#each (map-by “fullName” users) as |fullName|}}`


`{{#each usersFullnames as |fullName|}}`

where in the latter example usersFull names was computed property in the component which has the same map logic. Now this is a simple example but there are very complex one building temporary objects using hash or array which become lengthy and starts to meet the point where perhaps it’s clearer if written in the component instead of the template.

In my opinion, I like the helpers in the template for trivial things but for complex operations I typically stick with computed properties.

In some cases where you are relying on the currying perhaps it’s required but in others it may not be obvious which is preferrable. When a chain of the helpers is built up it can get confusing about what is happening to the data and having that computed property variable name giving semantic meaning to the resulting value can actually be more expressive or constant even if the underlying computation changes over time.

I would be interested to see what kind of decision tree steps or processes similar to the one in this article that people go through to decide when it’s appropriate to use which.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store