Adding or updating props and slots in code editor don't trigger auto-save

I think it makes sense to do this after 🐛 Auto-save changes from code editor get lost if you navigate out too quickly Active which will hopefully get in soon.

There is a @todo in there that points to this issue to add checking for props/slots changes and block navigation until that's been auto-saved.

🐛 Auto-save changes from code editor get lost if you navigate out too quickly Active got in!

I’m able to reproduce the issue — when I update props or slots under the Component Data tab without making any changes in the JS or CSS tabs, the updates are not auto-saved.

I’d like to start working on a fix, but I couldn’t locate the file where the auto-save logic should be added for props or slots updates. Could you please point me to the right place to make this change? Thank you!

Hi @meghasharma, the todo is under the proposed resolution in the second bullet, but I can see how that could be easy to miss.

if you do a search for this issue number "3525907" in the codebase, there is a todo inside of /ui/src/features/code-editor/hooks/useSourceCode.ts which is where the change should be made.

Hi @hooroomoo,
Thanks for the info. I tried the following in useSourceCode.ts:
Added deep comparison for props and slots using lodash/isEqual.
Updated refs to track changes in props and slots.
Triggered auto-save when props, slots, or source code change.
Verified dispatching compiled JS and CSS updates.

But the issue with auto-save losing changes on quick navigation still happens.

There's no indication that this didn't end up getting saved, and there's no way to explicitly save what's currently in the code component editor (everything goes through auto-save). So bumping priority and tagging .

wim leers → credited lauriii → .

Per @lauriii in chat: this is a borderline beta blocker.

I don't consider this a novice issue after working on it

@hooroomoo in #16: I don't know what I was thinking … I thought it'd be as simple as adding a .setChanged(true) or something like that … but clearly that wasn't the case 😅 Sorry!

@balintbrews confirmed me he's already started reviewing it, so reflecting that.

@wim-leers No need to apologize! 🙂I thought it'd be a simpler fix before working on it too

didn't mean to change the status and assignee oops

This is beautifully done, and the UX improvement is a great addition. @hooroomoo approved the two test cases I added in a DM, so I went ahead and merged after reviewing everything else and manually testing.

Tested changes on branch 0.x , for following scenario :

Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.