Add non-proxy alternative for StateLink.nested property

[dai-shi]

Continued discussion from dai-shi/react-tracked#1

[dai-shi]

if you can implement your lib without proxies that easy, you wouldn’t need proxies from the start, would you? That might be simpler.

[avkonst]

Thanks for the note. I have though about it and the original version was similar to the one without proxies. The difference with proxies and polyfill is documented at the end of this section.

Mainly proxies are lazily evaluated, polyfill is not lazy, it constructs nested object on get of a property. It is a trade off. Lazy is usually faster when only a segment of a state is consumed (most frequently the case with global states). If a user wants to drop proxies and speed up things, for example for JSON.stringify(state.get()), it is easy to do so with the Degraded plugin JSON.stringify(state.with(Degraded).get()). .with(Degraded).get() basically means all the properties (including all deeply nested one) are used from the usage tracking point of view, but proxies are not involved.

Secondly, proxies trap set() properly and block setting the value in the state directly (with an exception for symbol properties, which is frequently used by plugins). The exception is thrown and a hint message is shown to a user suggesting to use state.nested.prop.set(newvalue) instead of state.get().prop = newvalue. Polyfill does not trap the set method.

And thirdly, proxies allow to create state links for properties which are not defined on the target object. Polyfill does not have this functionality. More on this use case see the documentation for nested property of the StateLink.

Construction of proxies is only few lines of code in the library, so not a big deal from the complexity point of view.

I see the above is quite a good justification to have proxies. What do you think?

[dai-shi]

The first point is about performance. The second point can be replaced with Object.freeze(), but it's a preference. The third point is probably the most important I missed. I wasn't aware your lib supports adding a new property on demand.

Overall, fair enough.

[dai-shi]

Hi, I read your code a little bit more (unfortunately I don't fully understand it, but at least I understand, it's based on mutation like MobX), especially your ProxyPolyfill.

There was a misconception in our previous discussion.
What I propose is to use object getters instead of Proxies, and you can keep laziness.
The intuition behind this proposal is I learned that object getters is faster than Proxies.
If you are keen about performance, using object getters would improve it. (and you don't need polyfill.)
(and I'm interested in hearing the result 😄 )

[avkonst]

It is possible to add method: ``` StateLink<S>.pick<K extends keyof S>(propertyName: K): StateLink<S[K]> ``` `state.pick('prop')` will be the same as `state.nested.prop` but without using Proxy. I have got an idea to add StateLink.slice([props of interest]) - this can potentially be used to accelerate append 1000 rows to 10000 rows table, but it is another story.

…

On Fri, Feb 14, 2020 at 12:51 AM Daishi Kato ***@***.***> wrote: Reopened #6 <#6>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6?email_source=notifications&email_token=AA6JSVOUNA4KZPBN3KWUG7LRCUX5ZA5CNFSM4IQDJNJ2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOWTPV7IQ#event-3034537890>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6JSVKGRMH2M6UX7AHGOKTRCUX5ZANCNFSM4IQDJNJQ> .

[dai-shi]

What I mean and expect is that you can keep the same API with object getters without Proxies.
So, state.nested.prop won't change.
I might be wrong, but that's what I understand.

[avkonst]

currently nested[v] will always return StateLink object for any v.

…

On Fri, Feb 14, 2020 at 5:16 PM Daishi Kato ***@***.***> wrote: What I mean and expect is that you can keep the same API with object getters without Proxies. So, state.nested.prop won't change. I might be wrong, but that's what I understand. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6?email_source=notifications&email_token=AA6JSVOSJESFQERJW5M3NP3RCYLJLA5CNFSM4IQDJNJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELXQMGI#issuecomment-586090009>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6JSVPG3ZRSTRGZ3QDGEP3RCYLJLANCNFSM4IQDJNJQ> .

[dai-shi]

My assumption is that you already know what v will be. I mean, the precise type of v, not like string.

[avkonst]

V is a property name. You can assign non existing property by calling state.nested.newprop.set(new value)

…

On Fri, 14 Feb 2020, 18:06 Daishi Kato, ***@***.***> wrote: My assumption is that you already know what v will be. I mean, the precise type of v, not like string. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6?email_source=notifications&email_token=AA6JSVMHVWT4HPJXML3KMR3RCYRDRA5CNFSM4IQDJNJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELXS2QI#issuecomment-586100033>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6JSVIXVQ62C6NGKL7AKCDRCYRDRANCNFSM4IQDJNJQ> .

[dai-shi]

Oh, now I get the point. Then, object getters won't work.
Thanks for the clarification again.

This just a random thought, but if I were to design API without Proxy (tbh, I would like to avoid it whenever possible), I would probably do state.nested(new_prop, new_value), but this might confuse people because it also allows state.nested.existing_prop.