Drafts feature randomly resets the input field
I'm guessing it came about around the same time the draft feature was introduced.
OS: macOS 10.12.6
Browser: Google Chrome 68.0
I'm seeing different errors:
- Old drafts from different posts showing up when creating a new thread or a new post instead of a blank textfield
- Entire textfield getting overwritten with emptiness or with another draft while you're in the middle of typing (and even if you're just away to check something somewhere else).
- Textfield getting overwritten when the mentions popup "responds" (I only noticed this when the server is slow so the mentions popup seems to be not working).
I think this should be tested in throttled/bad connection mode.
My guess is this is faulty logic in the React Component state management. It's a typical issue that we've dealt with in our own components.
Needless to say this bug is huge since it basically makes the editor unusable for any longer text - you now need to write your text in another app and copy/paste it into Talkyard to be sure to not have it deleted. I think the drafts feature should be rolled back until it's proved to be more stable.
- 8 replies
Hmm the code does an async request when the editor opens, and then inserts any drafts text, once it's been loaded. I was thinking this'd happen within a second, before one had had time to type anything. ... I didn't test this on a slow network connection and then yes it's possible that one has started typing, and one's text gets overwritten later when the draft has been loaded.
So rolling back / disabling this feature, for now, seems like a good idea.
- Another thing that annoys me with drafts, is if I start editing something, then close the editor, and restart editing a bit later — then I have forgotten about the original edits, which I maybe didn't want to keep. But now they get loaded again, via the drafts feature. And then I might accidentally included the old edits although I didn't want to.
Very much agreed. We've implemented state versioning in all our React based rich text editors that are realtime cloud connected such as yours. The state versioning makes sure that no newer version gets overwritten by an older version loaded from a server.
We do this by storing text and version together in an object. Every single time your container react component receives a downstream change event from the input/editor, the component will increase its internal version. After that, it sends throttled events to server including those versions (the whole object, both version and content get stored in the drafts on the server).
Now that means, anything received from upstream (either via redux/flux/parent components or async requests directly within the compenent as you're doing it) will include a version in it as well that we can then check for. This works very reliably.
This complexity is however really only necessary for us because we have support for two-way realtime updates, but for this draft feature where you're only receiving once from the server it should be enough to keep track in the component of if the textfield is dirty when you're receiving the draft reply.
You could possibly also implement a browser storage "optimistic draft cache" again based on versions but that might be overkill. Anyway just ideas :)
Another thing that annoys me with drafts, is if I start editing something, then close the editor, and restart editing a bit later — then I have forgotten about the original edits, which I maybe didn't want to keep. But now they get loaded again, via the drafts feature. And then I might accidentally included the old edits although I didn't want to.
Ultimately does't the drafts feature make more sense if the drafts were more opt-in maybe? Like drafts in Gmail have become a huge time saver?
Like maybe the draft would get stored at the point in the thread where you were trying to write it. Then when you come back you'll see your reply draft (in the location where it would be if you had published it, but clearly stated "Draft" and maybe only a summary available) and you can either click on it to resume editing/publishing it, or you can hit reply anywhere else and get a fresh editor.
This way you will contextualise your drafts (like they are in Gmail) instead of them being tied with the editor.
I know the current editor code design is architected around a single editor instance. But ideally that is just a visual design decision, not a code design one. Replies and threads always have context. Allowing that to seep into the feature IMO would make it much more valuable.
For new posts they could turn up as drafts as well (of which you would then also have many lying around).
But in any case - it seems to me the drafts feature is something that should be tested in a safe "playground" because it is such a core part of the experience and very difficult to bypass since every action goes through it.
And fwiw drafts are not a huge concern or wish for us - just posting ideas since you were already going down this route.
Just tried it out (now where the server is back up and running I'm not getting the draft related errors - I still think it's important to fix the state bug though) and the draft just saved me because I was typing a reply, navigating to somewhere else to read a reply, and then back and my draft was saved. That was really nice.
So maybe this feature just needs a little tweaking here and there to sort out the bugs and then I'm starting to see how it can come in handy. I thought the drafts were only saved once per editor but the fact that I could navigate to a different thread and the drafts apparently are saved contextually is great!
This leads me to think my suggestion about how the drafts are visually presented is key to making the user experience really good... Maybe.
(in the long run, besides the bugfix for state I don't think it should be a big priority for now given the SSO and export features have far more potential for making stuff either work or not work).
- In reply tochrscheuer⬆:
@chrscheuer I've fixed this now, meaning, drafts can no longer overwrite text one has started writing.
I disabled the input textarea, with a message "Loading any draft...", until any draft has been loaded. That normally takes less than half a second. (Unless that QoS issue with too-many-open-tabs and additional-connections-prevented, is happening.)
if I start editing something, then close the editor, and restart editing a bit later — then I have forgotten about the original edits
if the drafts were more opt-in maybe?
Yes I'm thinking about making drafts for edits, opt in: They'll be saved automatically, and later on resuming editing, one will see a dialog with something like: "You have old unpublished edits. Do you want to continue editing? [Yes, continue] [No, start new] [Start new, delete old draft] [View edits]"
when you come back you'll see your reply draft (in the location where it would be if you had published it, but clearly stated "Draft" and maybe only a summary available)
I like this idea :- ) I have in mind to do the same thing, for flags, and other people's posts that are pending approval — so staff see those things too, although no one else does. Hadn't thought about handling drafts, in a similar way.
Hmm I think people fairly often wouldn't look below the post they're replying to — they wouldn't see their old drafts a bit below, and forget. Maybe the most recent draft should be auto-loaded anyway, + maybe a "You have drafts" indicator icon, next to the Reply button.
the current editor code design is architected around a single editor instance [...] For new posts they could turn up as drafts as well (of which you would then also have many lying around).
Yes, and ... Later when there's a rich text / WYSIWYG editor, then one could edit these "previewed drafts" directly by just placing the cursor inside, and continuing typing.
I thought the drafts were only saved once per editor
Actually there's a list of one's drafts, if you click your username menu (upper right) and then click Drafts, bookmarks, tasks. And if you click a draft, you'll jump to that page and the editor auto-opens. I use this drafts list as a todo list, to remember to reply to people (I click Reply, then type "r" in the editor, close the editor, and then a draft with the text "r", meaning "Reply later", appears in my drafts list).
Sounds good! It feels snappier and working better overall in general.
However I still sometimes encounter that I have posted something and then when I try to answer to another post/comment then I'll get the draft up for something that was already posted.
I'm not entirely sure when this happens / what the steps are.
Thanks for mentioning. Maybe these issues will be simpler to understand / troubleshoot, if I add the above-mentioned indicators that one has a draft saved, for this and that post. Then, if there is no such indicator, and a draft text / already-posted-text still appears ... something is amiss. i created an issue about that: https://www.talkyard.io/-164
- Progresswith handling this problem
- @KajMagnus marked this topic as Planned 2018-09-09 04:10:38.585Z.
- @KajMagnus marked this topic as Started 2018-11-01 10:22:41.266Z.
- @KajMagnus marked this topic as Done 2018-11-01 10:22:42.209Z.