[Feature]: Restore Pinia Support

[thombruce]

Feature request

But to what layer?

It doesn't seem necessary for blogging websites, right? So you might think it ought to be omitted from tnt-content.

On the other hand, the obvious place for it right now is in the core module, meaning it would be inherited by all, including tnt-content.

It's certainly desirable for tnt-electron, as it will be for Ionic/Capacitor and web applications.

It's also desirable for an online shop... probably. Think shopping cart storage.

And an online shop would also benefit from tnt-content (in some cases) as a simple way to list items in an online store...

🤔

Consider modules/layers like:

• tnt
• tnt-content
• tnt-electron
• tnt-pinia ??
• tnt-blog
• tnt-shop

What differentiates tnt-blog from tnt-content? Kind of nothing... I listed it as an example of an idea. tnt-blog would extend tnt-content, whereas tnt-shop would extend tnt-content AND tnt-pinia, creating a handy single layer with the features needed to publish product pages and host an interactive shopping cart.

This is an exercise in thinking about... is tnt-pinia the right call? Should the Pinia store functionality be on its own layer, extending the core module?

Still trying to figure that out.

As of now, I think it's so universally useful that it probably should exist on core... and can be ignored entirely if it isn't actually wanted. And at least that way if I were ever trying to call it from core or from any other layer, we would know it exists. It does seem that universally useful, yeah...

I think that's settled. Slap Pinia in TNT Core and figure out how to use it in the Toodle project, particularly how to use it in conjunction with the Electron module.

Code of Conduct

• I agree to follow this project's Code of Conduct

[thombruce]

• c7deec3 - adds and demonstrates use of Pinia
• bf9d9b4 - Modifies usage of Electron API to return data in Promise (rather than separate broadcast/listener pattern)
• 0b69f1b - Separates file-read/write logic into new API scope
• 52986f1 - Adds support for reading/writing files by any name

A lot of that isn't strictly Pinia-related, but it has been put to good use on Toodles:

• thombruce/toodles@ca2c991 - creates a basic store and loads content from a file
• thombruce/toodles@6cfab9a - separates some logic into a new model scope
• thombruce/toodles@bea9945 - adds some functionality to the model via the store module

Notably, have had to make use of Lodash's _uniqueId(). Wondering if we should install nanoID for convenience or leave that to individual projects... _uniqueId() does seem to be doing the trick - identifying the correct item when we are trying to amend data. It is a basic solution but fit for purpose when dealing with a single-user, single-machine, from/to-file kinda logic.

If we were adding client-to-server or client-to-client logic, I would want something more robust when defining these IDs... but that would also make identifying content from file a little trickier too (no ideal way to match a non-IDed file content to its IDed counterpart). Best solution is to store the ID inline, in-file with the content it identifies. For Toodles, that would probably be a case of ! (A) This is a todo with id:n4n01d; alternatively we could just ID the document and store/update that on the server... but the server might then need to replicate a lot of the application's query logic which, particularly in the case of Toodles' custom format, would mean some amount of redundancy? Or... we could store the documents and not worry about the query logic on the server at all - simply download the document(s) and handle all querying/editing locally. And if two people were trying to patch the document at the same time... I don't know how to handle that. It is a lot easier if they're adding/updating individual todos - less likelihood of collision, less data being transmitted back and forth over and over.

Yeah, I think maybe on a server a standard table-based database solution makes the most sense still... despite this leaning towards custom document formats I've been going for. We already do store the document in memory as an object thanks to Pinia, so... we already have a means of handling document content items separately for communications with a server. The tricky part then is identifying the parts of the document to update when we request and receive updates from the server... 🤔

We could make use of document path and line number to identify contents... but line numbers may change. Heck, even document path may change. 'Tis better to have IDs for both... (Toodles could support a document ID by making use of its obsolete todo feature: ~ id:d0cum3n71d - lines beginning with ~ are considered "obsolete"; alternatively, we might consider finding something which precedes ! alphabetically so that a theoretical "meta line" could sit at the top of the document, even when sorted... unfortunately the only easily accessible character which does precede ! is , a blank space).

For Toodles, it isn't necessarily too late to make # the focus character and reclaim ! for metadata... but I'm not sure I like it. ! has nice semantic meaning for marking an item as important.

Consider also, meta line need not be denoted by a single character but could begin !! id:something or !# id:something... or we could look to read an obsolete (~) line from the bottom (or first instance anywhere in the document containing the meta tags we're looking for) of the file. And I do think that's my favourite approach... should we need it.