`setStyle` & `setComponents` options parameter not taken into account

Thanks @mcottret the fix is ready for the next release

Unfortunately, due to the bad initial naming, avoidStore is intended to skip the UndoManager and not the Storage 😁 The good news, I had to introduce the new noCount option, in order to fix #3189, this will skip triggering the editor changes counter so, it won't trigger the Storage either. That fix brought me also to update properly the signature in handleChanges from CssComposer, but I still need to fix a few other methods to make the whole thing work properly (including those you've suggested).

So, in the next release, the thing should work as you expect with the new noCount option, and, probably, I'll start using a new noUndo option (leaving avoidStore to avoid any breaking change).

ps. as always, thanks for your help ❤️

Hello @artf !

I'm sorry to reopen this issue but the setStyle issue still seems to be present.

Redoing the steps above, the "Stored ..." log still appears while calling setStyle with the noCount option.

I'm seeing the fixed handleChanges handler still uses the avoidStore option, but the avoidStore option does not seem to work either.

I didn't look deeper into this so I couldn't identify why the issue persists, but let me know if you want me to :)

Everything works fine with setComponents on the other hand, thanks a lot for that :) !

Thanks for reporting this, @mcottret.

The issue with setStyle & setComponents options parameter not taken into account appears to be a race condition or state management timing problem. This typically happens when component lifecycle events and DOM modifications overlap, creating an inconsistent state.

What to try:

1. Add a setTimeout wrapper to ensure the DOM has settled:

setTimeout(() => {
  // your operation here
}, 0);

2. Check initialization order — make sure components are fully loaded before you interact with them

3. Use the editor's event system — listen to completion events:

editor.on('component:mount', (component) => {
  // safe to interact with component here
});

Recommended next steps:

• Test with the latest GrapesJS version if you haven't
• Provide a minimal reproducible example (CodeSandbox) — this helps the team identify the root cause faster
• Include GrapesJS version, browser, and console errors in your report