That's awesome to hear!

You're welcome and thanks for the Twitter follow!

Awesome

I wrote a little utility that allows me to perform array-like operations on an object (iterate in loops, push, pop, etc.) Using a proxy to achieve this ended up helping helping me account for unexpected user behaviors (eg. otherwise it's hard to catch a user running a push on what I deem a tuple in a runtime context). That's my little use case from earlier today. The world's second most popular typescript framework, VueJS, is also based on proxies. Turns out proxies are really good for setting up guardrails for how people use code, so if you can "prove" that users will write reasonably safe code, you can become more aggressive about state-management techniques. Vue's state model is better at surgical updates than say, React, because of the library's extensive use of Proxies (among other architectural innovations). Hope you found this response enlightening. Best wishes mate. - Oz.

Might be Open Sans

My guess is this proxy thingy seems to have more 'traps' than class, which has just two - set and get?

I believe that the use case demonstrated in this video was not a good example of a proxy. The real use case is when you want to perform some extra work behind the scenes that is not directly related to the object itself. For example you might want to save the game settings object in a SQL db, Redis cache, document cookies or local storage or etc... You might want to listen to the changes in the game settings properties and send them over an external API to sync the changes across the player's devices and so on and so forth ... None of these tasks are directly related to the gameSettings object. The purpose of the game settings object is to just represent the settings and control how you set or get them, it's not meant to have the implementation logic for syncing settings across devices or saving them to a storage. Proxies provide a better way to handle these situations