Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stabilize cursor over re-renderings #115

Open
bantic opened this issue Oct 20, 2016 · 3 comments
Open

stabilize cursor over re-renderings #115

bantic opened this issue Oct 20, 2016 · 3 comments

Comments

@bantic
Copy link
Contributor

bantic commented Oct 20, 2016

It should be possible to use a heuristic to attempt to re-position the cursor at or near its position when the component's mobiledoc changes and the editor rerenders.
See #112 (comment)

@rlivsey
Copy link
Contributor

rlivsey commented Oct 20, 2016

The heuristic that we're currently using is to stash the section & cursor offset within that section and then to try and apply that back again post-render which we've found to be "good enough" in most simple situations.

If someone's added content in a previous section, then your cursor is kept in the same place in the section you're currently focused in. It doesn't handle the case of the current section having been edited before your cursor, as that ends up keeping your cursor at the same offset when you'd expect it to move if it were properly tracking the cursor (via OT/CRDTs etc…).

There's much more we could probably do in future with proper cursor tracking & collaborative editing, but something like this could cover the low hanging fruit.

I wonder if this is a job for ember-mobiledoc-editor or whether the code mobiledoc-kit should/could have stashCursor / applyCursor which the ember component hooks into.

@bantic
Copy link
Contributor Author

bantic commented Nov 2, 2016

@rlivsey Thanks for explaining your approach. I've been in favor for a little while of making the Position and Range objects in Mobiledoc "dumber" — right now they keep a reference to the instance of their Section, which isn't stable over re-renders (the Post references a different object for that section after the rerender). If a Position were simply a tuple of [sectionIndex, characterOffset] then it would be much easier to stash them and attempt to re-apply them later.
Do you think something like that would work for your current use case?

(And yes, in the future a CRDT structure would be even more bullet-proof because it could handle repositioning the cursor even when the content before it was edited)

@rlivsey
Copy link
Contributor

rlivsey commented Nov 2, 2016

A "dumber" Position of [sectionIndex, characterOffset] makes a lot of sense. As you say, that's what we end up stashing & reapplying so having that as-is without having to translate would be great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants