WixData.update should have no side effect

Ask the community
,
1

This is not really a bug but an issue I noticed with the implementation that goes against best practices.

When updating an item in a collection with https://www.wix.com/corvid/reference/wix-data.html#update the item argument is mutated by " Update".

Here an example

return wixData.query("collectionName")
 .eq("_id", id)
 .include('referencedField')
 .find()
 .then(result => {
   const item = result.items[0];

   console.log(typeof item.referenceField) // object
 
   return wixData.update("collectionName", item).then(() => {
     console.log(typeof item.referenceField) // string
   });
 })

Here is a link to a live example

I think that developers should not have to worry about their variable being changed by library code and that platform’s functions should not have (unexpected) side-effects.

Do you agree?
Are you going to do something about that?

1 Like
2

Is someone from the data team available? :slight_smile:

3

@plomteuxquentin That’s happening because you can’t update an object that includes a reference record (i.e. the updated object cannot include the “include” results).
if you want to keep the original object you should create a copy of it when you update:

const item = result.items[0];
console.log( item.referenceField);//object
wixData.update("images", Object.assign({}, item))
.then(() => {
    console.log( item.referenceField);//object
})
4

Hi J.D.

Thx for your reply.

But the code works as expect and it’s valid according to the documentation

When updating an item in a collection that has a reference field, set the value of the reference field to the referenced item’s _id value or the entire referenced item object .

Secondly, that’s not my point here. My point is that I should not have to worry that MY variables are mutated by Wix or any lib I use. Good practices dictate that a function should be as pure as possible (no side effect and agnostic of its environment), especially when you are not the owner of that parameter.

This is something I notice in this case, but it should be the rule for any public method develop by Wix

They are the one who should, indeed, do a copy before processing the update.

5

I think what J. D. is referring to is this part that you may not have read in the update function

If the existing item had properties with values and those properties were not included in the specified item, the values in those properties are lost.

6

I think that is meant for the collection storage: If a given property does not exist in the collection field it is lost and not saved. That would be normal behaviour.

If you are right and it refers to the method argument, I still think that’s not good practice.

Moreover, that sentence is really confusing and not clear at all.

7

@plomteuxquentin you’re right. It would have made more sense if they’d cloned the object and mutate the copy under the hood and leave the original object as is.
It is not something that we should take care of.

8

@sheyla , any input from the wix team? :slight_smile:

9

Hey Quentin!

I’ll bump this with our team to see if we can get some insight. :slight_smile: