I think this is all looking pretty fantastic. We are now using our new SQLite tools with the @SharedReader property wrapper for 4 different pieces of state: the collection of unarchived facts for the root view, the count of archived and unarchived facts for displaying that information in the view, and a collection of archived facts that are displayed in a sheet.

Some of this state is held in an observable model because that feature has a decent amount of logic that we may want to test some day. And an other piece of this state is held directly in the view because that feature is very simple and we don’t anticipate it becoming complex in the future, and therefore a full observable model may be overkill.

But most importantly, it doesn’t matter where this property is used. The @SharedReader variables always hold the most current data as determined by the database, and if some other part of the app makes a change to the database directly, the @SharedReader variables will automatically update. And the view will also automatically re-render.

Let’s now move onto to fixing some of the last remaining ergonomic quirks in the tools we have built so far. The tools are very powerful, but often it is not appropriate to write raw SQL strings from scratch when there are tools available to us to make these queries a little more type safe.

To motivate this we will see what it takes to make the query powering a @SharedReader state dynamic so that it can change when the user changes certain settings.

Let’s dig in.