[Engine] expose a way for 3rd party libraries to produce read only proxy objects

[caridy]

Description

LDS, and other libraries that produce objects might want to produce values that can be used as properties. Additionally, they want to tap into the internal mechanism of the reactive engine to produce reactive objects that can trigger rehydration.

Initially, we want to try this model with LDS, and for what, we we exposing a high-privilege (not-documented) api to LDS can import it.

[jbenallen]

Is the goal here to allow a library (LDS in this case) to emit an object to a wired property that is internally reactive such that one of its properties may be mutated later by the library without replacing the whole thing from the wire and that that internal mutation will be observed by the engine?

[caridy]

After thinking more about this, I think @jbenallen has a good point here. Today, it is impossible for libraries to trigger rehydration, because they don't have a way to produce reactive/tracked objects. More thoughts:

1. you can get a reactive proxy of any object via track() decorator today (libraries can attempt to do something funky to produce trackable objects (yes, it is a hack, but it is possible).

2. today, we don't prevent the extraction of a writable version of a read only attribute. they can hack it by assigning the field decorated with @api into a field decorated with @track, and they effectively escape the restriction. We should close this loop asap, and throw an error in this case.

3. You should be able to get a read only proxy of any object (no exceptions) to protect yourself when sending data like that to non-trusted parties.

4. I think a method called readonly() makes sense to be part of the library, to match the expectation of @track, and in the future, we can make readonly a decorator, and @track to also function as a regular method to have some symmetry there.

[davidturissini]

My only question about readonly as a decorator, is what happens in this scenario?

import { Element, readonly } from 'engine';

export default class MyComponent extends Element {
  @readonly
  foo = { bar: true }
 
  connectedCallback() {
    this.foo.bar = false; // Error or allowed?
  }
}

It seems we should throw, because that object is readonly, but you also own that object so this restriction may be strange

[caridy]

@davidturissini good question. It will throw because it is a readonly. Also, this.foo = {something: 'new'} should also throw, the decorator makes impossible to change that field after initialization.

[caridy]

keep in this open until we add the decorator and the docs.

[jmsjtu]

We reviewed this as a team and the readonly decorator as described in this issue can be achieved with a combination of signals + Object.freeze.

Closing this issue out.