Things are looking really good now. By moving the database connection to our dependencies system we have massively improved the ergonomics of using the @SharedReader property wrapper to fetch results from a SQLite database. We can now simply specify the query when declaring the shared state, and as long as we set up the database connection in the entry point everything will just work. And if we forget to set up the database connection we will get a helpful warning letting us know what needs to be done.

There are still more ergonomics improvements to make to how @SharedReader interacts with SQLite. For one thing, we have not yet dealt with dynamic queries. That is, queries that depend on state that the user can change, such as ordering the facts by the date they were saved or the number the fact is for. And another ergonomic problem is that we are specifying the query to power @SharedReader as a raw SQL string. It might be better to use a kind of query builder, like the one that comes with GRDB, in order get some type safety on the queries we write.

These are all things we can massively improve, and it’s amazing to see, but let’s have a little fun first. We now have a powerful tool for querying a database to fetch data, but we are barely taking advantage of these powers. Let’s add a few more features to this app so that we can see just how easy it is to incorporate all new queries for fetching data.

The feature we will add is the ability to archive facts that are no longer interesting to us, but that we don’t want to delete just yet. Archiving will remove the fact from the main list, but we will also add the ability to navigate to a screen for viewing all archived facts, as well as the ability to unarchive facts in order to bring them back to the main list.

Let’s get started.