Use cases for ES6 proxies

http://devbryce.com/use-cases-for-es6-proxies/

by inian • 10 years ago

83 32 10 years ago

devbryce.com

xpaulbettsx• 10 years ago

Here's one way we're using ES6 proxies at Slack:

https://github.com/paulcbetts/electron-remote

Create a proxy for an ES6 module that actually creates a separate process in a task pool and executes the method there.

cjhveal• 10 years ago

This is a great article. Proxies really have gotten lost in the hype around ES6. Surely it's in part because JS developers have obvious pain points with async control flow and clumsy syntax, so things like generators and generous helpings of syntactic sugar are the most visible changes. However, I'm inclined to think that the level of abstraction and the complex API make it difficult for many developers to recognize their use cases or even play around with them.

spion3• 10 years ago

Its because proxies are too hard to compile to ES5. Every function call, array access, property access etc is potentially going to end up calling a proxy, and as such will have to be compiled to impossible-to-read code.

Also, all of the examples given there can be implemented more elegantly using decorators.

The more useful cases are dynamically generated method names (e.g. for ORMs) and array index access (e.g. MobX) for non-array datastructures, both of which could've been handled with a less invasive language feature...

jannes2• 10 years ago

What do you think about immutable data structures as a use case? (e.g. https://facebook.github.io/immutable-js/)

qwertyuiop9243• 10 years ago

On the contrary, I can think of tons of uses for proxies, from Ruby-style MethodMissing, to object.observe functionality.

wrong_variable• 10 years ago

I didn't read the username but then saw 'MobX' and went 'wait a minute'

iamleppert2• 10 years ago

None of that code is any more clear, either conceptually or syntactically than a simply implemented and well designed library that does something purposeful and applied, like their "application" of handling validation.

And if you want "private" variables in javascript, just use a closure! Do people who write these blog posts even know basic javascript these days? If you really want all the features of java [said no one ever], than why don't you just.....use java??

It's just extra cruft we're going to have to support now in our javascript runtimes.

</slams door>

nickfargo• 10 years ago

just use a closure!

Of course, but that means allocating a closure object per method per instance. When people say they want private variables, they mean they want them available in regular prototype-mounted methods. Proxies are one way ES6 lets you implement that. (Another is to use a WeakMap structure alongside a constructor, where each instance created by the constructor is mapped to a separate object that holds the "private" properties of that instance. Methods close over the WeakMap, but, crucially, are defined once on the constructor's prototype.)

iamleppert2• 10 years ago

There's nothing preventing you from defining your private variable, method, whatever within the same scope as your prototype method. That could mean (for commonJS anyways) the same file. As long as you don't export those, they are effectively private.

adrusi• 10 years ago

I suppose I don't know for sure how JS runtimes implement them, but closures ought to be very cheap. They just need a reference to a static block of code and to any variables declared or referenced within. The most expensive part of using a closure is a heap allocation, and one extra allocation while creating an object in javascript is almost always negligible.

allendoerfer4• 10 years ago

Right when I started to enjoy the in some ways lisp-like style you can program in JavaScript all these ES6 stuff came along.

I have to say, I do not like it either. The problem is that now the language becomes more and more impure introducing syntax and keywords left and right. The language lives inside browser. The old ways to do it will never go away, it will just get worse and worse and become a mixture of all kinds of patterns. All of this just because some people cannot wrap their head around scoping and prototypes.

I am fine with the rapid pace of change in tooling or libraries, but I think browsers could improve in other areas (DOM), so we could still move forward.

gavinpc• 10 years ago

I agree with you and the parent, but let me play devil's advocate for a minute...

CSS? Put that sh!t in feature freeze, like, yesterday. Because javascript.

Javascript? Put that sh!t in feature freeze, like yesterday, because wasm.

Except... at least the reflection API's seem to "get it"—that you can't just keep adding features willy-nilly. I'll take a new metaprogramming feature that deprecates an equal number of old ones. And if you look at the MDN article the OP referred to, the reflection API is apparently intended to obsolete several existing built-ins. And as the OP also indicates, Proxy also lets programmers implement things that would otherwise be the VM's job.

But of course, unlike the auto industry, we can't actually realize obsolescence, so, like I said, I agree with you.

girvo• 10 years ago

Right when I started to enjoy the in some ways lisp-like style you can program in JavaScript all these ES6 stuff came along.

To be honest, it's _easier_ to do nice functional-programming in Javascript with ES6 in my opinion, just due to the cleaner syntax for destructuring assignment, lambdas, and block-scoped variables.

See: https://github.com/hemanth/ramda-repl

tlrobinson• 10 years ago

People have been doing pseudo-classical inheritance in JavaScript since forever ago, but every framework had their own slightly different way of doing it. Might as well give them a "blessed" syntax to standardize on.

qwertyuiop9243• 10 years ago

Well, if you weren't careful and didn't use UAP, proxies can save your bacon. They are also useful for object.observe like functionality. And that's pretty cool.

madeofpalk• 10 years ago

One use case for us was throwing an exception when accessing an undefined property, for a very specific part of our app. Made debugging loads easier.

scarlac• 10 years ago

This may be due to slow or limited support in Safari (no versions support it)

It's worth noting that Safari Tech Preview actually does support it. It shows from the compatibility table that he links to. I also tested it just now, in Release 8.

jannes2• 10 years ago

I think another reason is that ES6 proxies are impossible to polyfill.

My favorite use case would be Facebook's immutable library[1], which uses awkward set(), setIn() and updateIn() methods for changing its data structures. But as an ES5+ library it wouldn't want to require the consuming code to do ES6 transpilation.

[1] https://facebook.github.io/immutable-js/

vertex-four• 10 years ago

It could reasonably provide an ES5 API over a transpiled ES6 core, for ES5 consumers to use while allowing ES6 consumers to use its ES6 API.

__s• 10 years ago

I have an AI which spends a large portion of time cloning game state. I'd consider proxies to implement ergonomic copy-on-write if they were portable

lrsjng• 10 years ago

another great use case is dependency injection as seen in https://larsjung.de/ghor/

zbjornson• 10 years ago

A lot of these use cases are achievable using Object.defineProperty/Properties. In most cases I think defineProperty even provides a nicer API because it's per-property instead of per-trap. The 'has' trap can't be achieved completely with defineProperty (although you can make a property non-enumerable, which achieves the same goal in some cases).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

inian• 10 years ago

One case where proxies are useful is when you do not know the properties of an Object before hand. Object.defineProperty cannot help you there..

Use cases for ES6 proxies

Related Stories