📄️ Why have a schema?
Verdant requires all data be defined in a schema. That may seem cumbersome, but knowing what data looks like is essential to changing the shape of that data over time as your app evolves. Data lives on user devices, not your servers, so getting migrations right is very important—data loss or corruption can be unrecoverable, and no backups exist.
📄️ Generating the client code
Using your schema, you can generate your typed client code using Verdant's CLI.
📄️ Migrations
Every schema change requires a migration, including the initial one. When you increment your schema version number and run the Verdant generate CLI, it will automatically generate the migration files for you and create a copy of your schema for use in future migrations.
📄️ Indexes & Querying
By default you can retrieve lists of all documents in a collection, or just one by its primary key.
📄️ Documents & Entities
Queries return Documents. A Document provides a .get method to retrieve properties, and a .set to set them - as well as other utility methods depending on its type. All root documents are Object Entities, which also provide .update. Since Documents can contain arbitrary sub-objects, you can retrieve lists off them, which comes as List Entities and provide some common list methods too.
📄️ Undo, Redo, and Batching
Local changes are undoable as long as you don't refresh the page. To undo a change, call client.undoHistory.undo(). To redo and undone change, call client.undoHistory.redo().
📄️ File storage
To work with files in Verdant, you add a file type field to a document. From there it acts similar to other fields, with a few notable peculiarities.
📄️ Exporting and importing data
Verdant clients can export all local data, and even download remote files if needed to include in the export.