Local post thread drafts

[mary-ext]

To-dos

• Validation schemas for saved drafts
• Ability to save drafts
• Modify composer reducer to accept the draft entry
• UI for user to view and restore drafts

Native

• expo-sqlite persistence (the only place that seems to make sense)
• Ensure that images are converted to data URIs

Web

• IndexedDB persistence

[gaearon]

what's your thinking on schema changing etc? do we need to stay diligent with it? only evolve it in backwards-compatible way? where does validation happen?

[mary-ext]

I'm still blank on these unfortunately.

I think the versioning is still good to have, but if things can be introduced in a backwards-compatible manner then we should go that route.

As for where validations should go... I was thinking it should be closer to the UI so we can present users the ability to delete them, although we could definitely just delete these ourselves (very unsure on this, at least for mobile you have the option to downgrade the app, but that's not much of a thing on web)

[gaearon]

how do you want to handle media? it just gets serialized? what about videos?

[mary-ext]

Right now media files are saved as data URIs:

• on native, we don't have the equivalent of IndexedDB, where it allows us to put JS' Blob types on the DB row. our closest is expo-sqlite, which only ticks the "it's a database" checkbox.
• on web, we're already dealing with data URIs, no question there.
• since we're forced to serialize to string, I'm not sure if there's a good way to ensure that no one (could be a user with root access, could be the OS itself!) tampers with the files that are referenced by the draft entries. I'm not sure if there's a good way to ensure we aren't doing anything wrong ourselves either.
• so data URI it is, since that allows us to put the media files directly on the DB row.
• I don't think data URIs would do so well for larger files like videos, so the prompt for drafts is currently disabled for videos.
• It also doesn't mesh well with the fact that we are uploading the video eagerly, prior to tapping the Post button, if the user decides to abort their draft or whatever, then that's bandwidth wasted, not good for users.
• Twitter doesn't do drafting for videos either, I think this is mostly because they don't want to store videos that are likely never going to be posted anyway.

GIFs could be supported but right now I'm not interested in finding out which fields from Tenor's API response we're actually using, so I decided to punt on it later. I think it's a low priority though because GIF posts are mostly about sending a reaction to other users, rather than a post on its own (we disable drafts on replies as well, for now)