Svelte 5 TJSDocument Prototype
Greets @FVTT ▹ Developer.
As some of you might have seen there is a bit of paradigm shift that is going to occur when Svelte 5 drops with a new way of defining reactive state. Please check some of the recent discussion in the #dev-lounge for links to the Svelte 5 blog post and a few other things.
https://svelte.dev/blog/runes
https://svelte-5-preview.vercel.app/docs/introduction
I just worked up a potential prototype in the Svelte 5 REPL for what this could bring to TJSDocument for direct property access and reactive manipulation. The prototype simulates the Foundry document model update cycle. This demo is naive in many ways, so is bare bones code.
What I'm curious about is how folks feel / think about how the new dynamic reactive properties should be exposed in the TJSDocument API. The demo adds a new behind the scene property state management that dynamically creates Svelte 5
$state instances for properties defined in a documents schema. I made this accessible from a new getter on the TJSDocument instance itself; $. In the demo the naive document has a name and count properties. You can reactively access them via doc.$.count / doc.$.name. You can drop those into wherever things can be bound and setting the values automatically will invoke update via the Foundry document model (this is simulated).
This potentially addresses a way to dynamically access document properties in a fully reactive way that automatically updates the underlying document data transparently. This needs to be vetted in real world conditions once Svelte 5 drops! I have yet to think about how document flag access could be dynamically created.
You can check out the demo on the Svelte 5 REPL here:
https://tinyurl.com/tjsdocument-svelte5-25 Replies
Definitely play around with the demo code and let me know if you like or dislike the
doc.$.<property> syntax.
Essentially the $ stands for state / separating it from the TJSDocument instance via $ allows things to be cleanly managed; for example if you set a different document to the TJSDocument wrapper then the state management accessors change if it is a different document type.
I gather system properties for instance would be doc.$.system.<property>.
An idea I have for flag access is to also provide a function in TJSDocument $flag. So flag access would be like this:
doc.$flag('<package id>').<property>I feel like using $ for getters is against the concept of runes, at least what I've seen from Rich Harris and Huntabyte demos
The general issue is that I'll be separating the management code;
DocState.js in the demo code from the main TJSDocument instance for cleanliness and better management of the accessors that are dynamically generated. state would be the longer description and I felt that doc.state.<property> is just not as nice.I guess it depends if your goal is to make syntax closer to the original concept or look nicer 😔
Some people who will learn Svelte 5 in the future and come to TJS might get confused by differences
Some people who will learn Svelte 5 in the future and come to TJS might get confused by differencesThe reactive label
$: won't have baggage for anyone that learns Svelte 5 and uses TRL. The runes use a preceding $<rune>. $ in general is a stand in for "reactivity".
This is a curious case for Foundry in particular since TJSDocument is a wrapper around the Foundry document model. So this syntax is very Foundry specific as whatever DB / document model is conceived of for a potential off Foundry / mainline Svelte version of TRL has the flexibility to not have the baggage of needing to wrap around a foreign DB / document model.