TyphonJS•9mo ago

Dynamic Reducers use cases

I am currently in the process of rewriting how the Titan system handles some things, and I was wondering about whether I should start using the dynamic reducers. Way back when I first made the system, the TJS dynamic reducers didn't exist yet, so went through the process of setting up my own item list component for character sheets. Essentially, the component is a reactive list that looks through an actor's item using a filter function (such as type === 'spell', etc). Then it creates a svelte component for each item that matches the filter (such as a Character Sheet Spell Component) and inputs the item's ID. The filter can be changed at runtime in response to user input. The item component then looks up its item like so: $: item = $document.items.get(id); This way, whenever the item gets updated, the actor sheet of the owning actor also gets updated. Similarly, I am able to modify the item with controls from the actor sheet like so:

            
<IntegerIncrementInput
    bind:value={item.system.quantity}
    on:change={() => {
       item.update({
          system: {
             quantity: item.system.quantity,
          },
       });
    }}
 />

            
<IntegerIncrementInput
    bind:value={item.system.quantity}
    on:change={() => {
       item.update({
          system: {
             quantity: item.system.quantity,
          },
       });
    }}
 />

So what I am wondering is, is it worth it to convert to using the dynamic reducers when I already have components that do the heavy lifting of sorting / filtering items, as well as updating the actor sheet in response to item changes? Are there any additional benefits I would gain from doing so?

3 Replies

TyphonJS (Michael)•9mo ago

I think it's best to save your dev cycles in regard to any significant rewrite until the coming Svelte 5 transition is clarified. This will likely occur later this year probably in the 3rd quarter. There will be plenty of things to do just in the Svelte 5 conversion process let alone any new TRL mechanisms created in regard to reactive integration with the Foundry document / data model. While Svelte 5 will remain backward compatible it is unclear when the old way will be fully deprecated (re: Svelte 6 or 7). With TRL I'll be aggressively adopting the new way forward. Many things will change in that process. It isn't clear to me yet how TRL adopting the new way will impact devs building on top of TRL. For instance reactive statements $: item = $document.items.get(id); changes significantly with Svelte 5 and new mechanisms developed for TRL document model support should remove the necessity of creating custom components like IntegerIncrementInput. So any potential rewrite should be able to leverage more standardized support from TRL itself rather than custom solutions. There likely will be enhancements to the existing dynamic reducer support as well which will clarify use cases. All this being said. It doesn't hurt to make a solid pass at your current efforts to tidy anything up that may not be working or could work better with current capabilities. I'll certainly try to mitigate any major changes where possible, but the Svelte 5 transition and moving forward is one of those large paradigm shifting moments in regard to how one will write modern Svelte code.

SolidorOP•9mo ago

Alrighty! Good to know! I'll probably do some normal cleanup. I have finally been able to get a regular group together to play, and while overall the system works, I have been noticing some things were just broken, possibly by foundry V11. So I need to go through and fix problems as I discover them anyway

TyphonJS (Michael)•9mo ago

I think having a solid working base for your system is going to pay dividends moving forward with any significant rewrite. The next TRL release really solidifies the current state / will do the same pre-Svelte 5 transition.

Gaming

Programming

Dynamic Reducers use cases