ID attribute is being removed/ignored when using getComponents

[bt-mkt]

Since v0.22.9 getComponents() seems to be removing/ignoring the id attribute from the component attributes list (at least on my end it is).

Is this behaviour intended? A bug? Or something I have to change on my end?

Coult it be related to __clearAttributes which was added in this version?

Is there anything I can check on my end? The main issue is that since it's not keeping the id and a new one is provided, any css set on that component (for that specific id) is lost on the next load.

Thank you for any advice or input.

@artf

[mohamedsalem401]

Hey @bt-mkt

• __clearAttributes() only exists on the component view, and it’s only used when updating the actual DOM element’s attributes. It doesn’t affect component.getAttributes() or editor.getComponents().

Are you using inline styles? That might help narrow down where the issue comes from.

Try adding a component, give it an id, then run:

console.log(cmp.getId());
console.log(cmp.getAttributes());

If the id isn’t showing up in both, then there might be an actual issue.

[bt-mkt]

Hello @mohamedsalem401,

I've created a new component to test on, no traits, just some style and classes.

This is the result I am getting with 0.22.5, on which getComponents() gets to retain the id attribute, (ignore the object before the id here)

getComponents result for this component on v0.22.5 -> {"type":"bla-bla","style":"","classes":[{"name":"bla-bla-comp","private":1}],"attributes":{"id":"iivx"},"components":[{"type":"text","content":"Test comp text","classes":[{"name":"text-block","private":1}]

This is the result I am getting with 0.22.9, on which getComponents() stops retaining the id attribute.

getComponents result for this component on v.0,22.9 and onwards -> [{"type":"bla-bla","style":"","classes":[{"name":"bla-bla-comp","private":1}],"components":[{"type":"text","content":"Test comp text","classes":[{"name":"text-block","private":1}]}]

Please let me know if I am doing something wrong, or there is anything I can improve/check/add to have it behave the same way as in prior versions.

The init and block events seem to have the same values, although getComponents is different.

Thank you for the reply and sorry for the late answer. You can see the component code below.

export default (editor) => {

	editor.DomComponents.addType('bla-bla', {
			isComponent: _isComponent('bla-bla'),
			model: {
				defaults: {
					'custom-name': 'Test component id',
					classes: [
						'bla-bla-comp'
					],
					style: {
						'text-align': 'center',
						width: '100%',
						margin: '0 auto',
						'max-width': '700px',
					},
					copyable: true,
					stylable: false,
					traits: [],
					components: [
						{
							type: 'text',
							content: 'Test comp text'
						}
					],
					styles: `.bla-bla-comp a {
						color: red;
					};
					`
				},
				init() {
					console.log('log in init -> ', this.getId(), this.getAttributes());
				},
			},
			view: {
				init() {
					console.log('log in view init -> ', this.model.getId(), this.model.getAttributes());
				}
			}
		}
	);
}

[bt-mkt]

Do you have any update? @mohamedsalem401

[bt-mkt]

@mohamedsalem401 @artf
Could the issue here be that we’re now returning only the props that have changed, as per the implementation here?

grapesjs/packages/core/src/dom_components/model/Component.ts

Line 1687 in 6370546

getChangedProps(res: Partial<ComponentDefinition>): Partial<ComponentDefinition> {

If that’s the case—and there’s no plan to change this behavior or add some form of control—I can create a workaround. I just want to confirm whether this is the intended behavior going forward, so I don’t need to revisit or adjust things again later.

There’s also another change that affects earlier versions:

When avoidInlineStyle is enabled, component IDs no longer seem to be mapped to CSS rules during initialization (this didn’t appear to be the case prior to 0.22.9). As a result:

• Component IDs exist but aren’t used in CSS selectors
• Styles are applied to class selectors instead of ID selectors
• Multiple components sharing the same class receive the same styles (rather than being component-specific)

Could you please confirm whether these changes are intentional and expected to remain? If so, I’ll plan accordingly and implement workarounds specific to my use case.

Thanks for your time.