This is the very barebones beginnings of a demo implementation of an alternate tiddler store. It is not functional. If using the Vercel builds, open developer tools in the browser to see it failing due to the absence of basic wiki methods.

The plan is to build it up into the smallest possible plain JS wiki store implementation, sharing as much implementation as possible with the existing core implementation with as little code duplication as possible. It could then serve as the basis for future experiments with wiki stores based on SQLite (@linonetwo), or a custom append only database (@yaisog).

See https://github.com/Jermolene/TiddlyWiki5/pull/7329/files#r1126709318

And make the demo storage areas switchable

@joshuafontany's implementation was in #7521

…pendencies

We get a reference to sqlite3 but we're not yet doing anything with it

Also note that this approach leads to duplication - there will be two copies of sqlite3.js and sqlite3.wasm in each generated HTML file. The plan is to dynamically retrieve those tiddlers from the store area rather than baking them into the raw markup area

empty.html with the plugin is now 4.1MB

Makes for an empty size of 4.1MB

Removing indexers and title cache

At this point, the result is incredibly, painfully slow – the wiki will probably fail to load entirely on mobile

Makes the code complex and is hard to keep up to date

…slower

Otherwise date fields will get saved as JS date objects, which are not properly defined in JSON.

This commit (a) is very much work in progress (b) improves performance significantly and (c) is actually broken

Right now, theme stylesheets don't get loaded for some reason.

I plan to spend some time improving debuggability by adding a SQL console

Very bare bones, but functional. Results are displayed in JSON for the moment. The console should also perhaps be hidden by default, with a keyboard shortcut, and a setting in local storage.

Improves rendering performance by a factor of 4, but we're still 5 times slower than the plain JS store

Perhaps it would be better to keep the tags in the desired order in the database...

And introduce some very simple tests

Using NULL was working against the grain of SQL

This roughly halves the bootup time of the prerelease wiki

Doesn't actually appear to make any appreciable difference

Previously, we were using the existing addIndexer method to piggyback adding our own internal indexers.

At the moment the optimiser returns a list of chainable functions, it would be simpler to just return a single function

Thanks @pmario