4

After spring 20 release update in my sandbox i'm finding that non-cached apex response object cannot be extended and the lwc controller is throwing exception "Cannot add a property x, object not extensible".

I believe after spring 20, the controller runs in strict mode where you can't extend the response object. I can get away from this by cloning the object. eg. let data = { ...result}. Not sure if this is going to break in future.

Again, this cloning gets applied only to the top level object, if there are object inside an object, this doesn't work. In that case stringifying the response will fix, but again this is not mentioned in anywhere.

We have lwc code deployed to production with object extensions and will break once this update gets into production.

Does anyone face the same issue? Any suggestions

UPDATE: I find this is inconsistent behavior, some of the existing components with api version 46 works with object extension. I guess this is a bug.


Just to clarify on apex controller, i'm not using any cachable methods but an @AuraEnabled method. I believe this is not cached and hence the response should be editable.

As i said, this was working before spring 20 and but now it has put more restriction on the client side controller irrespective of the api version, which is quiet annoying.

3

My team has faced the issue as you with multiple LWC components on Spring '20 preview org.

We found a post from Salesforce employee on Salesforce Partners forum which states that the problem has been acknowledged and the fix should be deployed this week.

The change is made by design and is about a unifying response from LDS, which in other areas (@wire) is immutable. Although the update broke many components, so Salesforce team decided to revert it. However, as I understand - it can come back in one of the next few releases, so we should make components future proof with object cloning.

5

Yes, this has been asked over and over here, and likely elsewhere as well. However, I'm not marking your question as a duplicate, as a matter of a slightly different nature in the wording deserves an answer.

The "cacheable" attribute that allows the same method with the same parameters to not have to round-trip to the server repeatedly (thus improving performance on idempotent method calls) requires that the object in the cache either be copied or marked read-only, because otherwise a developer could corrupt the cache.

The read-only option provides much better performance for large responses, so this was the design chosen. If you need a modifiable object, you are indeed expected to copy it to a new object, recursively if necessary.

You're right, as far as I can tell, it's a lacuna in the documentation (I think I may have wanted an excuse to use lacuna, I love that word). At this point, it's pretty well known for people who have asked about it, but someone should probably ask @salesforcedocs over on Twitter about it.

You'll want to make the appropriate changes to your code before Spring 20 goes live in production. Either the JSON.stringify/parse or rest-copy (depending on deep or shallow copy) should be forward compatible with all future releases of LWC.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.