use autosave rhs for spec

[tintinthong]

https://www.loom.com/share/eec55ba818994f39b69791bf22c46ae2?sid=b9ff9e70-7259-4507-a059-8d273b99c43c

[github-actions]

Host Test Results

    1 files  ±0      1 suites  ±0   22m 50s ⏱️ - 1m 17s
765 tests +1  763 ✔️ +1  2 💤 ±0  0 ❌ ±0 
770 runs  +1  768 ✔️ +1  2 💤 ±0  0 ❌ ±0 

Results for commit eed0784. ± Comparison against base commit 0d0443d.

♻️ This comment has been updated with latest results.

[FadhlanR]

The Playground panel also needs this mechanism. Could we add auto-save to the CodeSubmode component so it can be used by both the Playground panel and the Spec Preview? Or would it be better to have auto-save options in the card resource itself?

[tintinthong]

The Playground panel also needs this mechanism. Could we add auto-save to the CodeSubmode component so it can be used by both the Playground panel and the Spec Preview? Or would it be better to have auto-save options in the card resource itself?

Ok I see. I feel pushing everything up to code-submode will make it cluttered as others have complained about this before. Presumably, we want some sort of abstraction to make the auto-save reusable.

Do you think its a good idea to use another resource to encapsulate getCard that contains all auto-save features? This resource will react with changes in id.

[FadhlanR]

The Playground panel also needs this mechanism. Could we add auto-save to the CodeSubmode component so it can be used by both the Playground panel and the Spec Preview? Or would it be better to have auto-save options in the card resource itself?

Ok I see. I feel pushing everything up to code-submode will make it cluttered as others have complained about this before. Presumably, we want some sort of abstraction to make the auto-save reusable.

Do you think its a good idea to use another resource to encapsulate getCard that contains all auto-save features? This resource will react with changes in id.

I think it's a good idea. What do you think? @lukemelia @habdelra

[habdelra]

The Playground panel also needs this mechanism. Could we add auto-save to the CodeSubmode component so it can be used by both the Playground panel and the Spec Preview? Or would it be better to have auto-save options in the card resource itself?

Ok I see. I feel pushing everything up to code-submode will make it cluttered as others have complained about this before. Presumably, we want some sort of abstraction to make the auto-save reusable.

Do you think its a good idea to use another resource to encapsulate getCard that contains all auto-save features? This resource will react with changes in id.

TBH, this sounds like a feature of the store. like when you use getCard() you should be able to say that it should be an autosaved card. based on the very latest store refactor that was just merged that autosave flag would be passed thru the to the store service, and the store service would be responsible for binding and unbinding the autosave handler on the card instance's change subscription.

Also a refactor like this would eliminate one of the TODO's noted in the CardResource, which is to remove the onCardInstanceChanged optional param in getCard as the only place that is used is to wire up the autosave. moving the auto save into the store seems like a really good refactor. Unsure though, if you want to do it as part of this PR tho...

[FadhlanR]

Looks great!

[tintinthong]

The Playground panel also needs this mechanism. Could we add auto-save to the CodeSubmode component so it can be used by both the Playground panel and the Spec Preview? Or would it be better to have auto-save options in the card resource itself?

Ok I see. I feel pushing everything up to code-submode will make it cluttered as others have complained about this before. Presumably, we want some sort of abstraction to make the auto-save reusable.
Do you think its a good idea to use another resource to encapsulate getCard that contains all auto-save features? This resource will react with changes in id.

TBH, this sounds like a feature of the store. like when you use getCard() you should be able to say that it should be an autosaved card. based on the very latest store refactor that was just merged that autosave flag would be passed thru the to the store service, and the store service would be responsible for binding and unbinding the autosave handler on the card instance's change subscription.

Also a refactor like this would eliminate one of the TODO's noted in the CardResource, which is to remove the onCardInstanceChanged optional param in getCard as the only place that is used is to wire up the autosave. moving the auto save into the store seems like a really good refactor. Unsure though, if you want to do it as part of this PR tho...

Thanks @habdelra for the input. I have excluded this refactor and @FadhlanR will take a first pass at it in his playground panel auto-save pr

[burieberry]

Not the smoothest editing experience (sometimes autosave happens while still typing, and sometimes the spec panel disappears and comes back) but it works.

[tintinthong]

Not the smoothest editing experience (sometimes autosave happens while still typing, and sometimes the spec panel disappears and comes back) but it works.

I'll see if I can refine this after integrating with store auto-save fadhlan is working on