Make sure typed text is never lost

Codidact Platform Ideas
1

There are times when you make an edit to a post and something goes wrong while sending it. Or maybe you navigate to a different page (logging in after typing your post but before sending it) and what you had in the text editor is lost or reverts to the original version before edits. It’s pretty annoying at times. Please add some ways to make sure that any edits are always preserved.

2

I don’t think this is possible, especially if you are not logged in, and if you don’t want to have information leaks (imagine you anonymously ask a question about your misbehaving boss, and then your boss who’s sitting behind the same firewall and therefore has the same public IP opens up the site and gets to see your question …).

Instead, you might look for a browser-side solution (I remember there was a Firefox extension that saved input boxes locally; I don’t know if this still exists for new Firefox versions).

5 Likes
3

If you’re not logged in, you shouldn’t be allowed to type a post in the first place.

2 Likes
4

This is a useful feature and could be done with a client-side cookie. I don’t think we should include it in the MVP, however.

5 Likes
5

This would actually be quite plausible to implement an MVP on using window.localStorage web API.

Data is stored across sessions, we can use a basic form of invalidation based on creation date and current date. we could store it against a question’s ID and offer the user to restore the post when accessing the same question. If its posted, local storage is cleared.

3 Likes
6

It’s certainly not rocket science, but personally I don’t see it within MVP scope.

2 Likes
7

I wonder what “within MVP scope” means. I guess it means:

  • There’s a minimum feature-set and quality-level before we can call it a viable product
  • When we achieve that minimum, then we will release it and e.g. advertise it

But I guess it also means that other (unscheduled) features could be in the MVP as well:

  • If someone thinks they’re worth implementing
  • If they’re implemented before it’s time to release the MVP
  • If they’re accepted (e.g. as a merge request) into the code-base

Is there e.g. a reason why you’d refuse to accept this feature in the MVP, if it were implemented?

2 Likes
8

Not readily. I’ll explain my thinking process.

There’s one criterion for MVP: Do we absolutely need it? Remember, the MVP is 1.0 - it’s not even Alpha.

For this specific feature it’s not immediately clear. We can live without it, but it can be done in ~10 lines of js. Minimum effort. In that case it would depend on the overall effort required to merge, ie. “billable” hours spent by dev-leads on reviewing and QA-ing the PR, so I would defer to them.

So far I’m assuming that the required API endpoint already exists. If we need to add things in the backend to support this feature, then I propose we revisit the PR when another MVP use-case for the same endpoint arises.

There’s a third argument, however, A bit of a meta argument. Proposing ideas is easy. Anyone can do it. Submitting PRs is a bit harder. Fewer people do it. Reviewing those PRs is done by dedicated people, who are few in number, which makes it a lot harder.

I propose that it is our duty, as people who self-select as those who care about this project, to consider the noise-to-signal ratio, and not add to the cognitive load of others unnecessarily.

For this reason alone I would be negatively inclined to accepting any PR that is not in the roadmap or the backlog.

5 Likes