Popcorn Initiative
Just opening a forum post to track @gerark progress w/ TRL & Svelte + an initial idea of implementing "popcorn initiative"... 😄
32 Replies
So ye, I'm planning to go easy with the first implementation. It will be rough on many aspect. I don't have any intention on changing the existing combat tracker. I generally dislike the idea of creating overhaul on top of something that can change over time ( especially if it's a core aspect like the tracker ).
Definitely. I think the next step is installing
essential-svelte-esm and just getting a feel for some of the things you can do and investigate how things build and look from the TRL / Svelte component side of things.I read what you wrote about TRL but it's still hard to grasp that for me. Is it some sort of layer on top of Svelte so that it's easier to, I don't know, manage App Window and other components?
For example what would be the gain for me to use TRL for something like a Window which is displaying a list of actors treated as toggle buttons + some extra confirm/cancel button?
TRL manages the Svelte mounting process and Foundry Application lifecycle smoothly. It also is easy to use a TRL "ApplicationShell" component that fully replaces the core app window with a significantly more powerful window that has everything that possibly can be made reactive so out of the box. You still provide the main content however you like.
I think it is reasonable as mentioned to install
essential-svelte-esm and just check out the demos to get an intuitive feel for how things work and also peruse the source code for the demos. There is a lot to potentially "grok" so to speak on possibilities.I will then. Thank you for the info! I think I'll try something like this: Try to go with raw Svelte and then immediately after I manage to see a window ( empty window is fine ) I step to TRL. I think it will be easier for me to understand what's under the hood 🙂
Yeah... You can bespoke mount Svelte components in
activateListeners, but yes, there is a lot more available in TRL if you choose to use it that will make life easier. Drop in when you think you might be moving forward with things.I'm building the TRL template but I have a little question. If I want to distribute the module do I have to provide all the content in the template folder? It looks to me there are way too many things which are not needed, if not in development. Should I run a different npm command to pack things?
Also, I must say that I tried the TRL demo. It rocks, I think I'll just go with it without passing from raw Svelte 😄 it's gonna save me tons of time.
One thing that probably isn't explained clearly yet in the demo / template repos is that there is a Github Action that bundles / packs all resources in the way Foundry expects when you make a release on Github. Check out this line of
.github/workflows/main.yml for precisely what is packed and change it for your needs as necessary:
https://github.com/typhonjs-fvtt-demo/template-svelte-esm/blob/main/.github/workflows/main.yml#L33
By the end of the year I plan to have a simple CLI together that makes creating and building a standard TRL project easy without having to maintain the Vite config file. I'll probably also include a pack command for the CLI.
Re: capabilities of TRL. I have spent full time+ effort for the larger time span between Oct '21 and now working on it, so it's been rock solid for a while and I take a very deliberate approach to writing software, so bugs / issues are rare. There is a lot there and I'm constantly improving or adding new capabilities for advanced app dev w/ Svelte and beyond. A lot more is coming.
My end goal is to continue to add new capabilities, but also make TRL platform neutral and release it for the larger web dev / Svelte community while keeping Foundry compatibility.
Oh yeah... Something that is worth noting is that the Vite config and way that things are setup is specifically intended to work for the dev server for HMR particularly on Foundry when you directly check out a repo into the Data/modules/<package name> folder. It is not desirable in general to put the bundled index.js in the root of the folder, but to have HMR work in relation to the Foundry module.json manifest that is the only way I could get it to work seamlessly.
What IDE are you using? I can give some extra IDE configuration tips for WebStorm that are very handy for setting up intellisense for Foundry and easy debugging. That is more of a hassle w/ VSCode and I haven't yet looked into putting together a guide for VSCode.Everything's clear 🙂 So the repo is used mainly for development while the package running through github actions will just give me only the bare minimum files required.
I'm using VSCode, never got a chance to work with WebStorm actually. Talking about that I wonder if I can actually manage to have some sort of "debugging" enviroment where I can use breakpoints as well. Not sure how hard that would be in that setup.
It's super easy in WebStorm and rather powerful re: debugging instance. You can set breakpoints in Foundry code and if you link the system as well you can also set breakpoints in the system code and of course your project code. I'll put together a forum post a little later / maybe Wednesday for WebStorm.
VSCode is a bit trickier as it's finicky and not as good IMHO as WebStorm. Most folks symlink the Foundry client code into their project which is janky.
You can also get a free OSS license for WebStorm if you have OSS activity in the last year publicly on GitHub. In WebStorm you can setup library instances and link external code in a more reliable way that works for intellisense and while debugging. However, if you a re a pro dev $80 a year for a WS license isn't an issue and worth it. I've been using JetBrains IDEs for over 20 years and they have very much been worth paying for / supporting the company.
The best way to understand the Foundry API is to directly dig into the Foundry client code to understand it vs using the API docs. I almost never refer to the Foundry API docs and just go read the comments / code directly.
The TRL API docs are cross-linked between TRL code / Svelte / and TS lib declarations + links to Foundry API code, so are more comprehensive, so a reasonable resource, but it doesn't hurt looking at the TRL code as well. I'm still working on generating TS declarations / API docs for the Svelte components that are part of TRL and that will definitely be available by the end of the year.
Well, I could start using webstorm and learn a new IDE after all it wouldn't hurt.
All of the JwtBrains IDEs are very similar, so easy to get around them. It wouldn't hurt to spend a week with it as they might have a free month trial then choose the one you like. I think a lot of folks are enamored by "free" w/ VSCode.
I've worked with Rider for a while on some pet projects so it should be a walk in a park 🙂
JetBrains never disappoint me. Reference to the Foundry libraries now are working like a charm I think I'll spend the rest of the night trying to enable debugging so I'll be good to go from that moment on 🙂
Mmmh, I think I'll need some help for that. I think I'm quite there.
I'd like to be able to debug ( with breakpoints and all those stuff ) from webstorm while using the hot reload functionalities. I set the flag to false to start a server with "npm run dev" without having it to open. But I'm not sure why when I start a debugging session from webstorm the breakpoint are not breaking as intended. It feels like the code breaks on the minified version ( but I might be completely wrong 😅 )
If, instead, I run the app in debug mode from webstorm without running the hot reload thing ( with "npm run dev" ) i get the breakpoints correctly. I wonder if these two concepts can't be mixed at all.
not sure why ( just-popcorn-initiative is my module )
Also I get a bunch of breaks in
overlay.ts utils.js and greensock\esm\index.js. Probably it's normal but I'm not entirely sure.