TyphonJS (Michael) Comments - Answer Overflow

Topics

TyphonJS (Michael)

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

Or some comments explaining that the basic Vite config is configured for the template repo and installing the repo directly in the Foundry modules section. One is free to do whatever makes sense for ones own project setup from entry points to symlinking and beyond.. The Vite config provided works for the demo repos. It's basic, but it also is just a normal Vite config without additional code or complexity.. While we did have a discussion on Discord and I took a look at how you setup things I opted to keep things simple and just retain a normal Vite config that if you look at the Vite docs is understandable. If one doesn't look at the Vite docs and doesn't know how Vite works well that is something to remedy. It's not that your personal preference / custom scripts or how the PF2E folks do things is wrong; it's just opinionated. While what is currently available in the demo repos also is opinionated insofar as opting for direct installation in the /Data folder it errs on the side of simplicity. I also do plan to make a CLI that is more comprehensive and easier to use for standard Foundry package installations; direct /Data installs or symlinking. I wish I had to time to make better template demo repos and content explaining how to get started and where to go if one desires to provide custom modifications.

125 replies

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

Yes. Vauxs contributed some Vite config changes that are handy. So good to check out the example repos.

125 replies

•Created by Wasp on 3/27/2025 in #typhonjs-runtime

TJSConextMenu throwing error about its activeWindow optional parameter

So... Instead of passing x / y try passing the event itself. It does look like your usage of TJSContextMenu was constructed from an earlier implementation in TRL.

TJSContextMenu.create({
    event,
    duration: 0, // If you really need to change duration.
    items: contextMenu
})

TJSContextMenu.create({
    event,
    duration: 0, // If you really need to change duration.
    items: contextMenu
})

This block of code is assigning the activeWindow parameter from the event which allows it to function cross window IE say when popped out: https://github.com/typhonjs-svelte/standard-base/blob/main/src/application/menu/TJSContextMenu.js#L100-L106 It's also worth looking at the create signature. There is no transitionOptions, but there is duration if you actually want to change that. Also you don't need to explicitly assign a zIndex as Number.MAX_SAFE_INTEGER - 100 is the default. I can probably refine how various arguments to create are handled a bit in 0.3.0, but if passing the event solves your current usage I don't think an additional 0.2.x release is necessary. The only immediate improvement I can see is perhaps allowing x & y to actually be considered (line 118/119):

{
 x: x ?? focusSource.x,
 y: y ?? focusSource.y,
}

{
 x: x ?? focusSource.x,
 y: y ?? focusSource.y,
}

4 replies

•Created by Wasp on 3/27/2025 in #typhonjs-runtime

TJSConextMenu throwing error about its activeWindow optional parameter

I'll take a look and have an answer Saturday and may push out another 0.2.x release. To handle cross window checks not all JS engines are the same so I introduced a utility class [CrossWindow[(https://typhonjs-fvtt-lib.github.io/api-docs/classes/_runtime_util_browser.CrossWindow.html#iswindow) that does explicit to more duck type checking and this may be a case where that fails to work as intended.

4 replies

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

#runtime/svelte/component/core is now #runtime/svelte/component/application

125 replies

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

Just a note: a minor patch fix went out for the standard library 0.2.1 that fixes a rare edge case that most won't hit. The modal file picker support now is guaranteed to work for users under heavy load / many active modules. I only received one user report of this occurring and indeed they ran many modules. Just a note for those following this post. TRL 0.2.x should be rock solid. Please do update to it as 0.3.0 will be coming out with minimal API changes soon to address Foundry v13 core platform changes.

125 replies

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

Greets @FVTT ▹ Developer, TRL 0.2.0 is finally officially out. I am exhausted and won't have time to make a release video today. On a whim I'm taking this small window I have and hitting the mountains for some ski practice this week. This is something that I didn't really get to do last winter as I made TRL a priority. TRL 0.2.0 is a culmination of ~1.2 years of work considerably hardening and refining the API surface / features and all backing tooling behind TRL extending into contributions to other 3rd party OSS that TRL depends upon. It's this maintenance and hardening that makes TRL rock solid. This release is "peak Svelte 4".... There is a lot more work ahead. ---- 0.3.0 will only focus on Foundry v13 support for the new CSS layers changes. You are strongly encouraged to upgrade to 0.2.0 now if you want to release your package for v13. There should be minimal API changes, but you'll need to make a new release w/ 0.3.0 for v13. I'm going to do my best to get this done ASAP. ---- Some of the recent work is fully flushed out TypeScript support for the PF2E & League community types in addition to honing type support in TRL. In between the last RC release and now there were significant changes to the #runtime/util/object sub-path export. I thoroughly cleaned up and optimized this code and everything is very useful for JS / TS use cases in regard to type guards and type inference. There is not much chance that folks are using the functions that were dropped or likely using this package at all. It's used internally to TRL, but available for all. In particular deepMerge is super handy. It's like a deep Object.assign with type inference and works better than foundry.util.mergeObject in that regard for JS & TS. You'll notice all of the demo code for defaultOptions merging is now using deepMerge. So, just do a search in your codebase if you use #runtime/util/object just in case. I don't think many of you are using it yet, but this is a handy package.

125 replies

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

Greets @FVTT ▹ Developer! The likely final release candidate / RC of TRL 0.2.0 is available now: - [email protected] - [email protected] A lot of the work through January involved tightening up precise type declarations across TRL converting various sub-path exports to Typescript as necessary to get just a bit of extra control that JSDoc + TS can't deliver currently. I highly recommend that any of you that have active packages using TRL update to this RC release as this is a final chance to raise any concerns before the final 0.2.0 release. Of course I can always make patch releases to 0.2.x, but I'm going to be immediately switching to 0.3.0 and working on Foundry v13 compatibility. If you are on an older TRL 0.1.x release and have not updated yet there will be some minor refactoring involved. See the first post in this thread or raise any questions that you might have. If you update to 0.2.0 my goal is to handle the v13 / 0.3.0 update in a way that won't cause any TRL API changes. It's not clear yet whether I'll have to introduce a new Vite plugin to handle any of the v13 CSS layers aspects. ---------- Latest API changes: WorldSettingArrayStore is renamed to WorldArrayObjectStore from #runtime/svelte/store/fvtt/settings/world. Automatic Animations was a main consumer here and already is updated. Not sure if any other packages is using this TRL feature. It's neat.. 😉 The additional array-object reducers are now all strongly typed for those using TS. TJSGameSettings / TJSGameSettingsWithUI are now strongly typed. Deprecated (until 0.4.0): SvelteApplication is renamed to SvelteApp. SvelteApp is re-exported as SvelteApplication, but I don't think there is a way to mark a re-export as deprecated. If you are using SvelteApplication consider changing it to SvelteApp. The re-export will be removed in 0.4.0. Your code will not break if you keep using SvelteApplication, but will in 0.4.0. The reason for the name change is that this shortens the class name. In the type declaration work there is now a namespace with additional types of the same name. This just makes it more convenient to use / less space for those using TS. ---------- Reminder: There has been updates to all Vite configs in the demo / template repos to fine tune DX just a bit more. You may very well want to examine the Vite config for changes. The biggest change is being able to have build assets automatically named by the package ID in the respective package manifest and output to a dist/ folder. Hopefully, somewhat soon I'll get an official TRL CLI out that will make manual management of the Vite config a thing of the past. ---------- All demo repos are updated with the latest release. essential-svelte-esm template-svelte-esm and the TypeScript template repos: template-svelte-ts-pf2e template-svelte-ts-league

125 replies

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

Just to keep folks updated. I've been continuing to work through various areas of TRL converting certain sub-path exports to TypeScript that benefit from stronger and more accurate typing than what is possible from JSDoc. This current round took a bit longer, but the results are fantastic especially for those working with TS. TJSGameSettings and the additional array-object reducers are now strongly typed. IE these sub-path exports:

#runtime/svelte/store/reducer/array-object
#runtime/svelte/store/fvtt/settings
#runtime/svelte/store/fvtt/settings/world

#runtime/svelte/store/reducer/array-object
#runtime/svelte/store/fvtt/settings
#runtime/svelte/store/fvtt/settings/world

To not commit the cardinal sin of making a release before the weekend of which I won't be available for most of it I'll be delaying the next release until ~Monday evening or thereabout. This will make TRL mostly fully covered with thorough typing. It's not like these areas didn't have types before, but in particular for the additional array reducers things things are now verified with A+ typing. I have a few other backend updates to make beyond that, but really want to wrap up the official 0.2.0 release ASAP to get started on v13 compatibility.

125 replies

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

Upgrade to next.8 / next.4. There shouldn't be refactoring for this update.

125 replies

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

OK... [email protected] is out. I fixed the SvelteApp.Options types issue. The problem was that when extending the ApplicationOptions interface of the PF2E / League types I didn't use Partial<ApplicationOptions>. The template repos are adjusted slightly to remove the necessity of using Partial in defaultOptions now. For those using TS please hit next.8 and next.4 hard to find any remaining declaration aspects that you'd like to see adjusted / fixed before the 0.2.0 final release next week. --- I have spot checked many of the more advanced TS types support added. The one downside currently is that there isn't a comprehensive TS demo repo like essential-svelte-esm that uses a wide range of the TRL API for type declaration verification. The API docs are solid and it all should work fine, but eventually it will be nice to have a standard demo / reference TS repo that covers a wide range of the TRL API. So yes, if you have a complex TRL package report anything that you think might need a fix.

125 replies

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

Just giving folks a heads up [email protected] and [email protected] is out. Now with rather comprehensive TypeScript support for both the PF2E and League types. There are now two template repos for TS: - template-svelte-ts-league - template-svelte-ts-pf2e The shim layer to generically support multiple sets of Foundry types worked out. There should be comprehensive support including TJSDocument / embedded collection reducers and in the standard library all of the C(R)UD dialogs to work with documents. Also regarding TJSDocument & TJSDocumentCollection the data passed through to subscribers is now normalized to action and data where data will always be an array. Foundry itself will send over a string or object in single document operations and arrays of the same with multiple doc ops. Normalizing the output to always produce an array helps to simplify downstream processing. Chances are no one is using this functionality, but worth noting as technically it's a breaking change though significantly better than receiving action sometimes and renderContext (v12 change) at other times. For those that already have set up TS repos with the previous release take a look at your template repo of choice as there is now a types entry that you need to add for the shim layer. I also have updated the ESM repos / Vite configs to output production builds to /dist, so there are some config mods that you might find useful. ----- From here I have a few more odds and ends to wrap up and hope to make the 0.2.0 final release on the upcoming Wednesday. If folks can hit this hard especially any TS devs that would be handy. I don't expect issues, but the template repos and my spot checking only covered only the most complex new types support. There are several cool new features / type checking against Svelte props / context values and more in any TJSSvelte.Config you provide. ----- I'm exhausted and will make a video & ping tomorrow. Just want to give folks especially in different time zones an early weekend heads up. Thanks for taking a look if you can...

125 replies

•Created by TyphonJS (Michael) on 10/26/2024 in #typhonjs-runtime

TRL `0.2.0` Release

You should use production builds while you work through the upgrade refactoring. Read the first message above in this thread because it details the main points to watch out for including the moving of localize from "svelte/helper". You have been through Foundry core refactoring between versions. This is similar though in the case of TRL the refactoring is mainly where things are located and not a change in functionality though there are a few changes to note again in the first post above. Use the API docs looking up symbols that can't be found. The latest versions are next.6 for the runtime library and next.3 for the standard library. I am putting out what I hope is the last "beta / RC" releases on next.7 / next.4 hopefully later today. Next week 0.2.0 final release should be out.

125 replies

•Created by geoidesic on 1/2/2025 in #typhonjs-runtime

Dropping items into ProseMirror causes error (how does enriched content work)?

--- That error log doesn't even indicate this is a TRL issue...
Take it up with the core team. You are doing strange things once again.

6 replies

•Created by geoidesic on 1/2/2025 in #typhonjs-runtime

Dropping items into ProseMirror causes error (how does enriched content work)?

It's the compendium in a compendium thing. What version of TRL are you using? Doesn't seem to be the latest 0.2.0 next. The latest should just silently fail. I am guessing you are using 0.1.3 for some reason. The ProseMirror transform paste handler is synchronous. There is no way to use the async fromUuid method to retrieve a document in nested compendiums in this manner.

6 replies

•Created by Vauxs on 12/30/2024 in #typhonjs-runtime

Live-changing Title

Heh heh... It's not entirely clear how many folks install essential-svelte-esm to check out various demos. At least I have organized them better than how things were prior to 0.2.0.

7 replies

•Created by Vauxs on 12/30/2024 in #typhonjs-runtime

Live-changing Title

You should check out essential-svelte-esm. Lot's of good demos there. The first demo ever made does this in src/view/svelte-application/hello-foundry/HelloFoundryAppShell.svelte.

<script>
   const { application } = getContext('#external');
   const storeTitle = application.reactive.storeAppOptions.title;
</script>

<input type=text bind:value={$storeTitle}>

<script>
   const { application } = getContext('#external');
   const storeTitle = application.reactive.storeAppOptions.title;
</script>

<input type=text bind:value={$storeTitle}>

7 replies