[5.4.0] Formalize data tiddlers

[Arlen22]

This PR

• adds a preloadHooks array
• adds a data tiddler serializer module
• uses tiddler.isPlugin for all plugin checks
• converts plugin parsing and serializing to use the data tiddler serializer since plugins are already considered data tiddlers.
• Does not change the default plugin type or add new plugin container formats.

This is related to #9068 and #9064.

Breaking Changes: 5.4.0

The major breaking change in this PR is that plugins must now be parsed like this.

const plugin = $tw.wiki.getTiddler(title); // the plugin tiddler
if(!tiddler.isPlugin()) throw new Error("not a plugin");
const { tiddlers } = $tw.utils.parseDataTiddler(plugin.fields.type, plugin.fields.text);

and stringified like this

const newfields = { type: "application/json" };
newFields.text = $tw.utils.stringifyDataTiddler(newfields.type, { tiddlers });

This adds the following methods to $tw.utils

parseDataTiddler(type: string, text: string): any;
stringifyDataTiddler(type: string, data: any): string;
isValidDataTiddlerType(type: string): boolean;

It adds the module-type datatiddlerserializer with the following interface.

interface DataTiddlerSerializer {
  name: string;
  parse: (text: string) => any;
  stringify: (data: any) => string;
}

Registered serializers are a hashmap on the $tw.Wiki.dataTiddlerSerializerModules static property.

It registers two data tiddler types

• application/json - the usual format that plugins use
• x-tiddler-dictionary - the format used for things like color palettes.

Under the hood both of these are data tiddler formats.

---

Data tiddler types are rarely interchangeable unless they have an explicitly defined relationship.

A plugin qualifies as a data tiddler, which inspired me to just make it official instead of accounting for all the cases of x-tiddler-dictionary. Of course, x-tiddler-dictionary has additional constraints. It cannot be used for a plugin, as it requires the data to be of type Record<string, string> (aka a hashmap of strings). But setting the type field is very explicit.

[netlify]

✅ Deploy Preview for tiddlywiki-previews ready!

Name	Link
🔨 Latest commit	fdaf9f6
🔍 Latest deploy log	https://app.netlify.com/projects/tiddlywiki-previews/deploys/68eadf85f8023100086c49bd
😎 Deploy Preview	https://deploy-preview-9336--tiddlywiki-previews.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

Confirmed: Arlen22 has already signed the Contributor License Agreement (see contributing.md)

[github-actions]

📊 Build Size Comparison: empty.html

Branch	Size
Base (master)	2421.1 KB
PR	2562.5 KB

Diff: ⬆️ Increase: +141.3 KB

⚠️ Warning: Size increased significantly.

[Leilei332]

IMO each should be considered deprecated, it should use forEach instead.

[Arlen22]

I was just tightening up the formatting. It's out of scope for this PR because each could be operating on an object or an array and I'd have to determine which it is before I make that change. So unfortunately I won't be able to do anything with that here. each may be deprecated, but that doesn't mean we're removing it, and it needs to be handled carefully.