There is a more functional approach available for the Ember
set methods that you may have seen or even been using,
get(this, 'item') instead of
set(this, 'item', value) instead of
this.set('item', value). When I first saw this I too wanted to write code like that in my Ember projects, after all, no one is immune to the touch of JS FP fever right? So I destructured the
Ember namespace, pulled
set into the current scope and… the end. Hope you enjoyed this article and thanks for… What? Oh you expected more did’t you? If you don’t think this article should end here then good, neither do I. Let’s take this functional syntax for
set and give them a little extra whompff. (whompff being partial application, one of the “side-effects” of JS FP, and I won’t make anymore jokes like that I promise).
When we’re done, we’ll create a decorator function that will allow us to decorate any namespace with our
Ember object in the first example below. Yeaya! Something for everybody!
import Em from 'ember';
Before getting to how we’ll customize
set, let’s discuss quickly the pros and cons of using ES2015 destructuring (above) to lift the default implementations of these functions out from within the Ember namespace. It’s a perfectly fine choice to make, just not one I’m fond of using because it requires boilerplate at the top of any modules which make use of the
set functions and management of those statements might become tedious.
Besides that fact I don’t want to remember to drop in destructured assignments for
set to each file and baking those statements into my files doesn’t feel good for me personally either. Lastly, JSHint will complain wherever the
set functions are destructured but not used within a module, spamming ye ole’
"components/super-elem.js: line 4, col 8, 'get' was defined but never used" and then what? Add some ugly inline suppressor
/* jshint unused:vars */ to silence the beast? No, not on something so ubiquitous.