changset.get on a belongsTo relationship returns a proxy

[jaredgalanis]

Relates to #543

@snewcomer thank you for getting that fix merged in so quickly for the mergeDeep issue on a hasMany! 💪

In testing out the v3.9.2 we realized we are still experiencing this issue in belongsTo relationships as well.

I have to take a break from the keyboard for a bit, but here's another breaking test to give you an idea of how it is occurring.

jaredgalanis@470a155

I'm happy to take a swing at fixing it later, but given your understanding of the internals it may just be more efficient if you know where the fix is to let you handle it?

Thanks again for addressing this so quickly! 😃

[snewcomer]

I don't think that can be fixed. We use a nested proxy to give you access to further nested levels of the object - either proxy to the changes or content.

What is your use case?

[RobbieTheWagner]

@snewcomer the use case is we didn't need to proxy these things before. Shouldn't changeset.get be returning the real values and not the proxy?

[snewcomer]

The problem our recursive proxy nodes solves is something that wasn't possible before without significant number of bugs. The ability to access any arbitrary node in the tree and return out either the original content or the changes. This is why you can access nested changeset properties without Ember.get now. unwrap on the proxy is maybe what you need it you don't access the leaf key.

[jaredgalanis]

@snewcomer, I'm sure I'm misunderstanding something fundamental to the way these nested proxies work that you're referencing, but just for avoidance of doubt, we're not talking here about a further level of relationship nesting, it's simply the relationship in the other direction.

Also the actual implementation use case is basically the same. We'd be accessing the belongsTo in an ember-bootstrap form element and we want to get the related record, not the proxy. We have at least one unique implementation where the belongsTo is in a power-select, but I think it'll come up in other situations too.

[snewcomer]

not talking here about a further level of relationship nesting, it's simply the relationship in the other direction

Yep that makes sense. I haven't documented it well, but we have tons of tradeoffs since 2.0. Accessing nested data has never worked well. This recursive proxy solution fixes this as long as you access the leaf keys.

adopted-ember-addons/validated-changeset#45

In your case, do you have access to the belongsTo record before it gets passed to e-p-s? If so, can you try calling belongsTo.unwrap() where this property is read?

https://github.com/validated-changeset/validated-changeset/blob/70e918a80fc1149a09e1f922afb5de710a7ce3ad/src/index.ts#L979

[RobbieTheWagner]

We could do workarounds like unwrap or accessing content directly, but I think this is quite a change from ember-changeset previously and not an intuitive experience. It's easy to miss one, and it would be ideal if we could restore the old behavior, so it can be used just like a normal model in forms.

[sebastianhelbig]

Not 100% sure if this is related or the same bug, but we recently stumbled upon this.

ember-data 5.0.0, ember-changeset 4.1.2

// changeset was created with an existing belongsTo relationship to collectionOfGoods

this.changeset.set('collectionOfGoods', null);

let collectionOfGoods = this.changeset.get('collectionOfGoods');
let name = this.changeset.get('collectionOfGoods.name');

console.log(collectionOfGoods, name);

=> null "Sortimentsname"

In my expectation name should be undefined.