Proxy error using vanX.reactive() with lists of nested objects

[jfillmore]

I have an API that returns a list of objects, each of which has an inner object. This use case seems best handled using vanX with a combination of vanX.reactive, vanX.replace, and vanX.list to render a list of UI elements.

At the surface level, this appears to work fine if you don't access inner objects:

items = vanX.reactive(
  [
    {
      foo: 'bar',
      baz: {kind: 'dessert', amount: 'lots'}
    }
  ]
);

makeItemGood = (item) => van.tags.li(item.foo)
itemListGood = vanX.list(van.tags.ul, items, ({val: v}) => makeItemGood(v))
// yields: <ul><li>bar</li></ul>

---

However, the moment you attempt to access baz, you get the error:

TypeError: 'get' on proxy: property 'baz' is a read-only and non-configurable data property on the proxy target but the proxy did not return its actual value (expected '#<Object>' but got '#<Object>')

For example:

makeItemBad = (item) => van.tags.li(item.baz.kind)
itemListBad = vanX.list(van.tags.ul, items, ({val: v}) => makeItemBad(v))

As a work around I'm currently rewriting nested objects as JSON strings and then parsing them when it's time to make use of them.

Perhaps I've misunderstood something here, however? I don't actually need nested state management, but have struggled so far to get reactivity working using vanjs alone under this scenario.

[Tao-VanJS]

I can't reproduce your issue. Things work normally on my end. See: https://jsfiddle.net/rt9L4pky/1/

[Tao-VanJS]

Hmm... found a bug after calling vanX.replace(items, ...): https://jsfiddle.net/jzhux7m9/

Will get it fixed soon.

[Tao-VanJS]

@all-contributors please add @jfillmore for bug

[allcontributors[bot]]

@Tao-VanJS

I've put up a pull request to add @jfillmore! :tada:

[jfillmore]

Thanks for the fast responses!

I investigated a bit more, and using VanJS 1.2.3 it seems fine with a minified build. Using the debug build, however, manifests the bug. The version of VanX used had no effect. More specifically, I'm using the nomodule versions.

Some of the relevant backtrace:

    at <triggering code>
    at van-x.debug.js:49:15
    at van.debug.js:167:29
    at runAndCaptureDeps (van.debug.js:21:14)
    at bind (van.debug.js:68:18)
    at Object.add (van.debug.js:88:90)
    at add2 (van.debug.js:185:24)
    at addToContainer (van-x.debug.js:54:5)
    at Object.list (van-x.debug.js:77:51)

[Tao-VanJS]

I think the specific error you were getting with the van.debug.js is fixed in 1.2.4 release. You can try to use the latest version of VanJS.

[Tao-VanJS]

I will fix the issue shown in https://jsfiddle.net/jzhux7m9/ soon.

[jfillmore]

Confirmed that upgrading fixed the van.debug.js issue. Thanks! Looking forward to the other fix.

It's been a lot of fun working with such a minimalistic but useful library.

[Tao-VanJS]

FYI, the issue was fixed in VanX 0.1.3. You can check out the sample app here: https://jsfiddle.net/ktugd4jq/1/