Svelte + SvelteKit
Svelte is a JavaScript framework for building user interfaces (UIs) that compiles your code into efficient JavaScript during the build process, resulting in better performance and smaller bundle sizes. Svelte focuses on reactive programming, where UI components update themselves when data changes, eliminating the need for a virtual DOM. Svelte Kit is an extension of Svelte that adds features like routing and server-side rendering, simplifying the creation of full-stack web applications. It provides file-based routing and supports server-side rendering, enabling faster initial page loads and improved search engine optimization. Svelte Kit combines client-side Svelte components with server-side rendering and serverless functions for a seamless development experience.
view the rest of the comments
I haven’t read the whole series, but will try to, but until I do I feel like I’m missing something. Why bother with locking at all in this case? Can’t you just check that the record hasn’t been changed and then tell the user if it has, or force a reload? What do you gain with the lock file here? I’m imagining just checking that the card record has the same timestamp you saw when you loaded the data the first time, or that a hash hasn’t changed, etc.
@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.