Make edit play nice with content-based cacheKey

[jonatanklosko]

Consider a file diff where the cache key is a hash of compared file contents, unambiguous and deterministic. In edit mode, the file diff object is modified and the new contents end up in the cache under the same key (currently the expected behaviour). If a diff is computed from the same contents later and gets the same content-based cacheKey, it will render as the cached edited content.

Making a structural clone of file diff with a different cache key before edit seems to be too late, and the original object is still modified. Ideally entering edit mode would copy the file diff and cached state as needed, then use a random/hash cache key, while making the edits.

Also, the cacheKey docs say this:

Please note that if you modify the contents of the diff in any way, you will need to update the cacheKey.

During edits, it's the library that changes the contents, so arguably the cacheKey should not stay the same to match the above invariant.

On the other hand, with persistState enabled, the cache key is used as the editing session identity, which is contradicting. Perhaps it should be a separate key provided for the edit mode?

[amadeus]

Yeah so all of this is a bit messy right now. There's actually some differing issues/inconsistencies between an edited file and an edited diff (yay betas haha). I have some work that's building off the removal of using filename for cache key that attempts to harden all of this a bit more.

Ultimately cacheKey was something that was always intended to be controlled by the dev, not us. There are some cases like partial diff hydration where we do modify an existing cacheKey if it exists, but the goal should always be that's a dev controlled value, not something we should generate for you.

As it stands however, edit (should) work a bit differently. The goal I am working towards and hope to happen in the next point release or two:

If you supply a a file or diff (with a cacheKey or not), then edit it, the edits remain internal and don't modify the externally passed in file/diff. Annoyingly we don't have an edit completion event (except for in CodeView at the moment). My goal is on edit completion we would give you back the new file or diff data structure, sans a cache key, and then allow you to set that, and potentially commit change or revert back to the original file/diff if you wanted.

If during an edit session, the component gets a new file or diff, we would always apply that (which would effectively change your file you were editing), however you could ctrl/cmd+z to revert back to whatever edit session you were using.

[jonatanklosko]

If you supply a a file or diff (with a cacheKey or not), then edit it, the edits remain internal and don't modify the externally passed in file/diff. Annoyingly we don't have an edit completion event (except for in CodeView at the moment). My goal is on edit completion we would give you back the new file or diff data structure, sans a cache key, and then allow you to set that, and potentially commit change or revert back to the original file/diff if you wanted.

This sounds great!