This repository has been archived by the owner. It is now read-only.

State machine for posts

Vicky Chijwani edited this page Jun 25, 2016 · 13 revisions

Posts move through various states based on user actions. Each user action may move a post from its current state to one of several possible next states, depending on the action. Since Quill uses an offline-first data model:

  • Current state = current post status + current pending actions
  • Next state = next post status + next pending actions

State matrix (excluding delete action)

Current status + pending actions User action Next status Pending actions
-- create draft create
draft (create) edit draft create
draft (create) publish published create
published (create) edit published create
published (create) unpublish draft create
draft edit draft edit
draft publish published edit
draft (edit) publish published edit
published edit published [1] edit_local
published unpublish draft edit
published (edit) unpublish draft edit
published (edit_local) publish published edit

Deletion

Current status + pending actions User action Next status Pending actions
new delete -- (delete immediately)
X (any other state) delete X delete [2]

Algorithm for data sync

It's pretty straight-forward:

  1. Upload posts with pending action == create.
  2. Upload posts with pending action == edit.
  • NOTE: this will overwrite any changes on the server that have not been synced to the app, but for now we'll live with that
  1. Download remote changes from server and update the db.

Special notes

1. Handling edits to published posts

For published posts, we want to make sure we don't publish edits automatically. So there will have to be a temporary copy on the device until the user explicitly hits "Publish". For this we have a special pending action called edit_local, which is never synced to the server (only posts with create and edit actions are synced). Once the user explicitly publishes, we simply set the pending action to edit and it will get synced in the next sync cycle.

There are 2 additional wrinkles:

  • What about posts that are edited remotely before the user publishes their changes? Right now the remote changes will be ignored during the sync, and eventually the local changes will overwrite the server copy on publishing.
  • What about posts that are deleted remotely before the user publishes their changes? As of now the local copy will be deleted.

2. Handling deleted posts that are yet to be deleted on the server

These posts are displayed grayed out, and are entirely unactionable until they are deleted remotely.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.