You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you've used React, then you're going to be familiar with React.Component. It's probably what you're extending every time you create a new stateful component. Here's a class component that does just that:
In JavaScript, there is a bit of a mixture between utility methods and enums existing as inherited prototype properties as opposed to utility methods and enums that only exist on the built-in object itself.
For example, Date is a constructable object, but constructed Date instances that inherit the built-in Date prototype object's properties will not have the now property. The now property only exists on (and is only callable from) the global Date object.
Creating an Object Access Logger With Proxy and Reflect
Creating an Object Access Logger With Proxy and Reflect
You can create an access log for a specific object using Proxy and Reflect, which can keep track of all getting and setting of properties on the object.
Proxy is pretty crucial for this pattern, and although it's not necessary to use Reflect in this specific example, Proxy and Reflect were introduced to ECMAScript together and share many methods that complement each other (Proxy.get/Reflect.get, Proxy.apply/Reflect.apply, Proxy.construct/Reflect.construct, etc).
This is a really powerful pattern, and access logging is just one possible use case.
There is a common misconception that hoisting means declarations are hoisted or brought to the top of the file, and are therefore available to be used anywhere in the module, but this interesting snippet from MDN says otherwise:
Conceptually [...] a strict definition of hoisting suggests that variable and function declarations are physically moved to the top of your code, but this is not in fact what happens. Instead, the variable and function declarations are put into memory during the compile phase, but stay exactly where you typed them in your code.
With these declarations already in memory, we can use them anywhere in the module, including when importing code, which allows us to declare imports and exports pretty much anywhere (note that I'm not sure why you would want to make a habit out of this, but it's possible to do so):