What does `Proxy.revocable(target, handler)` return in JavaScript, and what happens to the proxy once `revoke()` has been called?

## The shape of the API `Proxy.revocable` is a static method on the `Proxy` constructor, not a constructor itself — you call it plainly and destructure the result: ```js const { proxy, revoke } = Proxy.revocable({ secret: 42 }, {}); proxy.secret; // 42 revoke(); proxy.secret; // TypeError: Cannot perform 'get' on a proxy that has been revoked ``` The returned object is an ordinary object with exactly two own properties. `proxy` is a full proxy in every respect — same traps, same invariants, same defaults for missing traps. `revoke` is a function of no arguments that returns `undefined`. Note that the two are separable, and that separation is the whole design. You can pass the proxy to somebody else while keeping `revoke` to yourself; the recipient has no way to get at the revoke function from the proxy, and no way to reach the target through it either. ## What revocation does Internally, a proxy holds two references: the target and the handler. Revoking sets both to null and marks the object revoked. From then on, every internal method of that proxy throws a `TypeError` rather than consulting anything: ```js const { proxy, revoke } = Proxy.revocable({ a: 1 }, {}); revoke(); proxy.a; // TypeError proxy.a = 2; // TypeError 'a' in proxy; // TypeError delete proxy.a; // TypeError Object.keys(proxy); // TypeError JSON.stringify(proxy); // TypeError ``` The failures are loud and immediate, which is the point: a revoked capability should not degrade into an object that quietly returns `undefined`. A few things still work, because they are not object operations that reach an internal method. Identity comparison is unaffected — `proxy === proxy` is still `true`, and the value can still be stored in a `Map` or a `Set` as a key. `typeof` also still answers, reporting the kind fixed at construction time, because callability is decided when the proxy is created and not by asking the target. So a revoked proxy is a valid JavaScript value that simply refuses to be used as an object. ## One-way and idempotent There is no un-revoke and no flag to test with; the only way to know is to try an operation and catch the `TypeError`, or to track the state yourself alongside the revoke function. Calling `revoke()` a second time does nothing and does not throw. Because the revoke function is created together with the proxy and closes over it, keeping the revoke function alive keeps the proxy object alive too — but not the target, which was released at revocation. ## The memory angle That last detail is worth stating explicitly, because it is the practical difference between revoking and simply dropping your own reference. While a proxy is live it strongly references its target; anyone holding the proxy transitively holds the target. Revoking severs that link, so if the proxy was the last thing referring to the target, the target becomes collectable even though the recipient is still holding the proxy object. Dropping your own reference to the proxy would not have achieved that, because the recipient's reference keeps the whole chain alive. ## What it is for The motivating pattern is a withdrawable reference. You give a plug-in, a worker, an iframe-hosted script or a request handler a proxy instead of the real object; when their scope is over — the request finished, the plug-in unloaded, the session ended — you revoke, and every later use fails at the point of use with a clear error. That is strictly better than handing out the real object and hoping nobody keeps a copy, and better than a hand-rolled `if (disposed) throw` guard, which only covers the methods you remembered to guard. The caveats are worth stating too. Revocation applies to the proxy object, not to anything already extracted through it: if the holder read `proxy.config` into a local variable before you revoked, they still have that value, and if that value was an object they still have the object. A proxy is a gate on a reference, not a retroactive undo. And because every use after revocation throws, the holder's error handling has to be prepared for it — revoking a reference somebody is using in the middle of a loop turns into an exception in their code, not a graceful stop.