Issue #5199Opened June 23, 2023by rmadeiraneto0 reactions

BUG: Changes in component's attributes being reproduced in all the instances instead of just one

Question

GrapesJS version

  • I confirm to use the latest version of GrapesJS

What browser are you using?

Chrome v114

Reproducible demo link

https://jsfiddle.net/rmadeiraneto/t659usxv/39/

Describe the bug

How to reproduce the bug?

  1. Go to the blocks list and drag the custom component "example" to the canvas
  2. Three elements that are coming from a default attribute (array) are displayed in the canvas
  3. Select the "Example" component
  4. Go to the traits panel and click on the plus icon a couple of times
  5. This would add items to the array that is in the attributes of the Example component and draw them in the page
  6. Drag another instance of the Example block into the canvas
  7. Notice that the items that you added to the array are being also displayed in the new instance of the component

What is the expected behavior? When creating the second instance of the same component after changing the attributes of the first one, it's expected that the attributes of the second component would be the first array defined in the defaults [1,2,3] under customArray prop, instead of the manipulated array [1,2,3,4,5].

What is the current behavior? When we change the attributes of an instance of a component, since the reference to the default object is probably being preserved, we are also changing the defaults of the component, making our changes on a single component instance being reproduced in all instances of the same component. When GrapesJs assigns custom defaults to components' attributes, it needs to create a shallow copy of the objects. When making the same thing with strings or integers, instead of objects or arrays, the issue is not verified, that's why I think it is a matter of keeping the reference for the defaults' objects when assigning the component's attributes.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Answers (2)

artfJuly 4, 20230 reactions

Thanks @rmadeiraneto for the report. Yeah, unfortunately that's an issue if you're mutating arrays/objects properties in that way and to avoid that you have 2 options:

  1. Avoid direct mutations (assign new references when you have to update them)
  2. Define defaults as a function
defaults: () => ({ customArray: [1,2,3] }),

But unfortunately... the second options doesn't work right now 😅 I'll fix it in the next release

rmadeiranetoJuly 17, 20230 reactions

@artf using defaults as a function works, thanks for quick response and for providing the alternative fix on this issue. About the first suggestion, I think it's not about people should mutate or not the object, because we're talking about using the provided method (set). I'm sorry I didn't have the time to look at the source code, but you're probably mutating the defaults object inside the 'set' method, probably because the reference comes from early on in the component lifecycle. Again, without looking into the code, I assume that when you merge the defaults with the attributes of the component, you're keeping the reference to the defaults object instead of using a merge method that would return a copy instead, for example, the from immutable. I'll try to find some time to look into the code and suggest something more specific

Again, thanks for the alternative and for this amazing library, keep up the great work!

Related Questions and Answers

Continue research with similar issue discussions.

Paid Plugins That Match This Issue

Curated by issue keywords and label relevance to help you ship faster.

View all plugins

Loading paid plugin recommendations...

Browse Plugin Categories

Jump directly to plugin category pages on the marketplace.