Make Color.js proxy-friendly, resolves #305

[LeaVerou]

No description provided.

[jgerigmeyer]

@LeaVerou LGTM! I agree that comparing this.id === space.id isn't ideal... but I can't think of an obviously better alternative?

[stof]

should this have some @private jsdoc to let IDEs know they should treat it as private ?

[LeaVerou]

It doesn’t really need to be private, as long as it’s immutable.

[stof]

This will also close #220 due to not using private methods anymore

[LeaVerou]

Ok, merging this with a heavy heart 💔

[bakkot]

@LeaVerou There's a simple way to opt in to being transparent to proxies if you explicitly want that: access private fields by deferring to the actual object, instead of the current value of this. Similarly, compare equality by the actual object, not by the current value of this.

class Example {
  _ = this;
  #private = 42;
  method() {
    console.log(this._.#private);
  }
}

let proxiedExample = new Proxy(new Example, {});
console.log(proxiedExample.method()); // 42

That won't solve your problems with Vue specifically because it's not just a simple Proxy - it recursively Proxy's every single property (including _ in this example). (This incidentally requires a bunch of effort to work with built-in types and only works with a small handful they've special-cased.)

But you can interop with Vue specifically with a little more work, if you really want that:

import { createApp } from 'https://unpkg.com/vue@3/dist/vue.esm-browser.js'

function makeVueNotProxyBox(value) {
  return {
    [Symbol.toStringTag]: 'box', // using a custom toStringTag will prevent Vue from trying to proxy this thing
    _: value,
  };
}
class Foo {
  #bar = 1;
  _ = makeVueNotProxyBox(this);
  
  get bar() {
    return this._._.#bar;
  }
}

createApp({
  data() {
    return {
      foo: new Foo()
    }
  }
}).mount("#app");

(This assumes you want to make a thing work with Vue without actually depending on Vue. There's easier ways if you're specifically designing Vue components.)

[redzzy30]

@LeaVerou There's a simple way to opt in to being transparent to proxies if you explicitly want that: access private fields by deferring to the actual object, instead of the current value of this. Similarly, compare equality by the actual object, not by the current value of this.

class Example {
  _ = this;
  #private = 42;
  method() {
    console.log(this._.#private);
  }
}

let proxiedExample = new Proxy(new Example, {});
console.log(proxiedExample.method()); // 42

That won't solve your problems with Vue specifically because it's not just a simple Proxy - it recursively Proxy's every single property (including _ in this example). (This incidentally requires a bunch of effort to work with built-in types and only works with a small handful they've special-cased.)

But you can interop with Vue specifically with a little more work, if you really want that:

import { createApp } from 'https://unpkg.com/vue@3/dist/vue.esm-browser.js'

function makeVueNotProxyBox(value) {
  return {
    [Symbol.toStringTag]: 'box', // using a custom toStringTag will prevent Vue from trying to proxy this thing
    _: value,
  };
}
class Foo {
  #bar = 1;
  _ = makeVueNotProxyBox(this);
  
  get bar() {
    return this._._.#bar;
  }
}

createApp({
  data() {
    return {
      foo: new Foo()
    }
  }
}).mount("#app");

(This assumes you want to make a thing work with Vue without actually depending on Vue. There's easier ways if you're specifically designing Vue components.)

It's really sad that we have to resort to this. This should be a feature natively supported by JS, instead of having developers take care of it. If I knew private properties would be implemented like this, I'd rather not have them at all and just stick with the good old _private_property

[bakkot]

@redzzy30 You have to write code like in my example anyway if you want === to work. That's a consequence of the design of Proxies.