test: coverage for trait changeProp not set

[danstarns]

This PR is to add coverage and to start a discussion around changeProp and what should happen if the value is set or not.

Related Comments:

• Feature/data sources #6018 (comment)
• Feature/data sources #6018 (comment)

[danstarns]

@artf would love your guidance here on changeProp how we work with it with data sources and how we should test it.

[artf]

I'd say the initial reason behind the trait.value is like the default one.
So if it's defined it should be applied to the component model (like you already did) but at the end the trait should always read/write from/to the component model.

The trait.value right now it's an intermediate state, when you do trait.setValue, this should update the component model and the UI of the trait.

From Trait.setTarget you can also notice how we subscribe to the component model changes in order to update trait.value.
That means if you update the property directly from the component, that will remove the dataSource binding in the trait. Does it make sense? I'm not 100% sure, but in my opinion it does.

IMHO it's fine as it is right now, but feel free to post here your concerns

[danstarns]

That means if you update the property directly from the component, that will remove the dataSource binding in the trait. Does it make sense? I'm not 100% sure, but in my opinion it does.

We do store the data variables in an adjacent property called attributes-data-variable see in dev:

• https://github.com/GrapesJS/grapesjs/blob/dev/test/specs/data_sources/__snapshots__/serialization.ts.snap#L126

So I believe we should have synchronization even when someone updates the value directly, as the getters will look for the attributes-data-variable: KEY and then resolve the data var.