'Path' in Op parameter to Subscribe is non-sensical with ProxyMap

[justin0mcateer]

When using the 'subscribe' function with the 'ProxyMap' object, the path parameter provided as part of the Op object to the callback leaks internal implementation details of ProxyMap. Specifically, the paths will start out with 'data' (which is the internal Array in ProxyMap) and an array index, which makes no sense outside the bounds of ProxyMap.

I would expect that the path returns the key within ProxyMap and any descendant attributes, etc. As an example, I have a simple ProxyMap with string keys (eg. 'abc123') and a handful of properties. When changing one of those properties (eg. 'eventStatus') I get the following path in the callback: ['data', '11', '1', 'eventStatus']. So the key 'abc123' is returned as ['data', '11', '1'] because it is the value (key 1) in the 11th key/value pair in the internal 'data' array of the ProxyMap implementation....

[dai-shi]

Thanks for reporting.
Hmmm, I think this is a limitation by design. This applies to proxyWithHistory too in a sense.
While this is probably technically fixable, I feel like it will become too complicated.
Do you have any workaround on your end? (Basically translating ['data', '11', '1'] to ['abc123']?)

[justin0mcateer]

Right now, I am just looking at the object to see if it has a 'toStringTag' Symbol of Map and if so, getting the key value pair from the data Array. However, this depends on my code understanding implementation details of ProxyMap and it really only works for the simplest case. What if I have an object inside the ProxyMap that is modified? In this case the logic will likely fall over.

[dai-shi]

Well, based on current implementation being emulation, if you need "Op", I'd suggest to avoid using proxyMap. But, my general suggestion is the other way around. You should be able to create an app without depending on "Op", maybe?

[dai-shi]

Closing this as it's intended.

Not exactly related, but link to #567.