@tyler great question! This tutorial is less “here’s what we’re building in three steps” and more “here are three ways to achieve a goal, let’s explore trade-offs of each.”
In the series, locking is the last thing we explore to prevent conflicts and ensure no one’s data is overwritten. Not all conflicts are equal. Locking solves for some cases automatic resolution can’t catch, but also introduces complexity and adds limitations to the offline capabilities of CouchDB.
The various resolution methods work together. E.g., in a forced reload scenario, trying to save changes to a card that has meanwhile been deleted could make for a jarring experience, so our manual resolution UI would take care of this one.