Lancer system & TRL
Let's move the conversation over to a forum post as I have a feeling there could be a few messages. When I'm done w/ lunch I'll finish this initial post. 😄
82 Replies
A small correction - We don't actually use sveltekit. I was mistaken, saw the svelte vite plugin and thought that they were the same thing.
Anyways, the project, for context
GitHub
GitHub - Eranziel/foundryvtt-lancer: A Foundry VTT game system for ...
A Foundry VTT game system for LANCER RPG. . Contribute to Eranziel/foundryvtt-lancer development by creating an account on GitHub.
(The system's currently mid-rewrite)
Yeah.. I was going to comment on that.. ;P I've taken a peak at the system repo from time to time to see what is going on.. SvelteKit is definitely cool, but doesn't really have a place in respect to Foundry dev as FVTT dev is all 3rd party client code launched from the Foundry server.
I am interest though in
svelte-package / part of SvelteKit to see if that will work with component library distribution. https://kit.svelte.dev/docs/packaging
When I mention getting TRL to run on & off Foundry running on top of SvelteKit independently is where I'm headed with that; IE TRL providing the final mile / client side desktop app like API.Is TRL based on sveltekit?
might be a naiive question
No.. It's pure Svelte... SvelteKit is more of a way to run a server / routing / SSR for a web app. I'm sure they will be adding authentication soon. TRL is just a plain Svelte component library + other goodies all bundled together to provide a cohesive app dev loop.
I see
Well, sounds like it's irrelevant then :)
Our main goal in bringing more svelte into LANCER isn't just to introduce technical complexity for no reason - its that our actor sheets are, quite frankly, ugly. They've grown as we've added more features until they have reached a point that is untenable both from a code and (in our opinion) UX perspective. Component re-use and implementation of click-through workflows are our main goals, but Handlebars as a framework is just frankly not the best tool for the job anymore.
For Foundry dev w/ Svelte it's definitely not something I think fits into the picture. I'm certainly glad they are progressing w/ the final release though as a lot of the Svelte maintainers switched to working on SvelteKit and Svelte itself needs a little more love and attention and should be getting some PRs and new support in.. I have a PR for adding container query support that should get in soon.
that's good. I still don't fully understand container queries, but more tools in the toolbelt are always nice
It's good to experience the core API and push it to where it doesn't seem like a good fit. I had this experience w/ fully building out and polishing FQL / Forien's Quest Log. It's about as complex of a module that you'd want to build w/ the core APIs.
Heh heh.. I'm going to finish lunch though and BRB for more chat in ~20-30 mins.. ;P
No rush lol
Anyways, our specific goals are initially to replace specific actor/item sheets with svelte/TJS.
- Ideally we'd do this in as piecemeal a way as possible
- As mentioned, our sheets are very large
- Our rough plan is to essentially just convert any handlebars helper into a Svelte component.
- We don't use partials much, so this would be a pretty straightforward function -> file conversion.
- Ideally, we'd have a fallback mechanism to continue using any non-converted helpers.
- This seems trivially accomplished by using
{@html whatever} and a fake HelperOptions object reconstructed based on current context.
- In this way, we could essentially just convert the entire sheet as a tree top down. It might be overall faster to just do it in one fell swoop, but who knows
- Event handlers seem like they would be problematic, as any applyListeners step would likely not survive well under svelte re-generating the DOM.
- I don't really know a tidy way around this aspectregarding authentication:
NextAuth.js has recently rebranded as Auth.js and is currently in the process of porting the entire library over to WebStandard API (ditching any and all node deps) and framework agnosticity. In the wake of this, Auth.js Svelte has been released a few months ago
I see that LANCER uses Typescript. I couldn't get typescript to work with TRL. I can not find setting that'll let me import
@typhonjs-fvtt/runtime/applicationoh right - i forgot this potential stumbling block
There is typedefs for TyphonJS in the NPM package, but I can't for the life of me actually get them to work
If there were accurate and up to date Foundry community types that would make it much easier to enable TS declarations for the
application sub-module export. IE the one that has SvelteApplication (extends Application). Besides not being up to date the community types are built in a very heavy handed way pulling in all sorts of unnecessary dependencies behind the scene for everything that Foundry exposes. IE if the community types were bundled and had better tooling instead of the kitchen sink approach that is the current arrangement things would be a lot smoother.
I just can't tightly couple the community types w/ TRL... What do I do only ship v9 types / hard couple that to a specific release of TRL?
Essentially everything else in TRL has types except the meeting point between TRL & Foundry. I built a pretty slick ESM to TS declaration tool that generates bundled types from ESM code / JSDocs.