Just something quick to add, I'm totally for using this to create observalbe objects! Especially when you're linking your objects directly to DOM manipulation or something.
I fully understand Proxies now, thanks! However, I don't quite understand how Proxies would support the readability and maintainability of your code. The developer would really have to document this well for this to work. Binding your data client-side like this doesn't make sense to me either, I much rather have the server deliver the data to me when I really need it instead of delivering bulk data like this.
Vue and MobX use Proxies to create observables for their reactivity systems. But yeah I don't think they belong in regular application code, they're too "clever". But for frameworks/packages they have their uses.
Your "undefined proxy" would result in some very painfull debugging, as it hides the origin of the missing data and silences errors. Your program might not crash, but having "undefined" in every place of the UI is not exactly what I would call a win. Maybe using your seatbelt() function to generate more useful errors and/or safeguard accessing undefined object properties would be much more helpful.
If you think he doesn’t t know that , you’re a fool. He is merely demonstrating various things that can be done using proxies and having fun at the same time. There can be cases where you may need it too.
Graph can be accomplished with properties (getters?) alone - not sure how it'd be in JavaScript, but here's how it'd be in python - with 2 versions (story-centric vs person-centric) people = [] stories = [] class Person(object): def __init__(self, name): self.name = name self.read = [] self.liked = [] self.authored = [] @property def authored(self): return [story for story in stories if self is story.author] class Story(object): def __init__(self, title, author): self.title = title self.author = author @property def liked_by(self): return [person for person in people if self in person.liked] @property def read_by(self): return [person for person in people if self in person.read] class Story(object): def __init__(self, title, author): self.title = title self.author = author self.read_by = [] self.liked_by = [] class Person(object): def __init__(self, name): self.name = name @property def authored(self): return [story for story in stories if self is story.author] @property def liked(self): return [story for story in stories if self in story.liked_by] @property def read(self): return [story for story in stories if self in story.read_by]
You don't even need to use getters in JS. When you assign an object to a property, it doesn't get copied, you create a reference. Because of this, there's actually no problem to have circular references, it won't lead to "infinity" as the speaker said.
Populate can be done with getter and setter. No need for proxy. I love the second example 😍 And a little sad that we can't replace object prototype. It would have been really fun 😎🤣
This can be done even without getters/setters, you just need to track circular references. BTW - you can replace object's prototype using Object.setPrototypeOf (look it up on developer.mozilla.org).
You don't even need to track circular references. Just go through all the objects and replace the string references with real references to that object, and you're done. It seems like the speaker thinks that when you assign an object to a property in JS, it gets copied, but you only create a reference. Because of this, circular references are not a problem at all.
