Learning Ember by Proxy (ObjectProxy Part I) – Zenefits Engineering

Today we’ll run through a quick example of an ObjectProxy in EmberJS. Our example revolves around Ember’s computed properties, which we have explored in-depth previously on our engineering blog here.

Imagine we have an Employee model that’s a core model of our application. Engineers across our company will add computed properties to our model that is shared across a variety of pods.

In our contrived example, suppose we are now adding a product or pod that is only going to be used for Ember Conf (we’ll be there, see you in Portland!) this year. With our understanding of EmberJS, the first approach (as a habit) we might have would be to add our new computed property to our models.js file as follows:

In a growing codebase we might imagine that this isn’t really a scalable process: continually adding computed properties to the models.js in a knee-jerk response muddles code clarity and bloats code in the long-run. Using an ObjectProxy here would help prevent both perils, improving code clarity and minimizing code bloat.

Firstly, what is an ObjectProxy? Verbatim from the EmberJS docs:

An ObjectProxy forwards all properties not defined by the proxy itself to a proxied content object.

The one-off computed emberConf2016NameTag, and any others, will now be properly localized to our one-off application thanks to our ObjectProxy. Engineers on other pods of our shared codebase will not have extraneous computed properties to sift through when building product. Nice!

Stay tuned for the next part of this series where we’ll cover more use-cases of the ObjectProxy as well as an alternative to the pattern suggested here.

Source link