Convenient handling of Proxy type? about solid

[ryansolid]

These are great questions. I honestly do not know. Exporting Proxy seems straight forward enough but as you said I think the fact it's a proxy is not that important for the consumer so hiding it sounds intriguing. I have no idea whether we wouldn't just hit another oddity. That seems be an everyday thing with TypeScript.

@r0skar @neodon Have you hit any issues like this so far? Any suggestions?

[bluenote10]

Maybe it is possible to define the proxy type interface like that?

type Proxy<T extends any> = T & {
  get(): any,
  set(): boolean
};

This seems to allow treating a Proxy<T> as if it was T. The following compiles:

const x: Proxy<number[]> = {} as Proxy<number[]>
const l = x.length
x[0] = 0

[ryansolid]

Ok, I mean if that does the trick then I'm pretty stoked. The last thing I want is to deal with unnecessary typings. If there are no objections I will change it and export the type from the project. I have no idea the best way to solve these things, but if that is a reasonable approach I'm all for it.

[bluenote10]

I only had a quick look at state.ts so I'm not fully sure what it is doing. After reading up what a Proxy is, I'm a bit surprised that it is defined as

type Proxy<T> = {
  get(): any,
  set(): boolean
}

According to the docs I would say a Proxy is best described as either type Proxy<T> = T or Wrapped<T>. The get and set methods only exist on the handler passed into the Proxy constructor, right? I verified that by actually calling state.data.get() and state.data.set() which should exist according to the type definitions, but both give runtime errors (TypeError: state.data.set is not a function).

I'm also confused by the wrap function, where the actual Proxy constructor is returned as a Wrapped<T>:

function wrap<T extends StateNode>(value: T): Wrapped<T> { return value[SPROXY] || (value[SPROXY] = new Proxy(value, proxyTraps)); }

How would you describe in natural language what a Proxy<T> and Wrapped<T> is? Is the wrapping on root level different from the nested wrapping or are they the same?

[ryansolid]

Got the Proxy from an example in a section in this doc https://www.typescriptlang.org/docs/handbook/advanced-types.html.

This was how they applied the Proxy to properly forward Types from T. Wrapped is the outputted Type which represented the Proxy wrapped state, it forwards all the keys from T, and shows that nested Objects are too wrapped, whereas simple primitives return their value. So I'd say Wrapped is more representative of the state object after it has been wrapped in a Proxy. There is no difference in whether they are top level or not. Looking at the code again I would expect you to be using Wrapped not Proxy. And Wrapped is the one that is exported.

[bluenote10]

Yes, the difference between the proxy defined in the examples

type Proxy<T> = {
    get(): T;
    set(value: T): void;
}

and the native proxy is that the example hides access behind explicit get/set wrappers, whereas native proxies still behave like T itself, but with access traps.

As far as I can see, we could simply remove the proxy type and define Wrapped as:

export type Wrapped<T> = {
  [P in keyof T]: T[P] extends object ? Wrapped<T[P]> : T[P];
} & { _state: T }

[ryansolid]

Yeah probably my misunderstanding of the example since you define proxies by accessors and it is super strange to have explicit set/get on the wrapped object since the point of proxies is to remove the need for that. If you can confirm this works seems like a simple change.

[bluenote10]

Yes, I've been experimenting with this change a bit, and so far it seems to work fine.

[r0skar]

I did actually run into the same issue shortly after I proposed the initial change to the Wrapped type, however I was so busy at work the last two weeks, I did not investigate it further. Can confirm that @bluenote10 changes seem to work fine so far.

[ryansolid]

Fixed in Solid v0.7.6.