Simply put, do we want the ability to have draft posts that are only visible to the OP and are saved?
I don’t have a huge opinion either way or if it should be part of the MVP, but it would probably be an extra status field in the DB and so I thought I would ask.
Yes please, if it’s no trouble.
I often see other people editing a post – write a little bit, save it, edit it, save that, edit, save again – that’s confusing, it invites premature comments, and you don’t know when/whether they’re done.
It (remembering an unsaved draft) is also a feature of SE and of Discourse – I don’t know (haven’t tested) whether that’s cached in the schema (back-end) though, or in the browser (front end).
There are a few ways to do this, none of them terribly hard to implement:
- Explicit “Save as Draft” function that creates a full Posts (or whatever table) record with IsDraft=TRUE (or IsLive=FALSE, depending on how we want to treat the status).
- Separate Drafts table of some sort, which automagically grabs stuff in process and automatically puts in the browser if you return to the same page. I have seen this in SE and I thought it might have been a local JS-based storage but I see it even if I pull up the page on my phone.
It’s a nice to have, but not essential. It certainly does not need to be in MVP.
It’s been useful a few times when my internet connection broke in the middle of writing a post, but that was maybe half a dozen times in as many years.
The few times I left deliberately before finishing a post, I always copied the text on my machine anyway. I guess I never really trust the system to save all my work.
We could also do this the way SE does it, by using Redis. That way, incomplete posts are kept out of the database, but still fulfil the need for saving and coming back later on.
For someone who doesn’t know how Redis works: how does that work? Is the draft kept purely client-side? Or is there some server-side layer that’s above the DB? Is your draft tied to a specific browser?
Drafts sound like a nice addition and don’t sound like a lot of work. I don’t think they’re MVP.
Redis is a non-SQL datastore. It’s still server-side, so drafts aren’t tied to a single browser, but its more lightweight than putting the draft into SQL is.
What SE does is definitely server-side because it works if I start on phone and finish on browser or vice versa. However, I see no reason to throw additional tech. in at this time. My concept would be to start this using the same PostgreSQL as everything else, but compartmentalized so that at a later time, depending on system impact (e.g., how many drafts per day) move it to Redis or some other system.