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.Yeah. Looks like you figured it out. Vite / dev server / HMR is not quite connected to WebStorm yet. Though I wouldn't be surprised if it is in the future.
You need to run a production build and use a JavaScript Debug instance in the run configurations. Just set the URL to http://localhost:30000/
Actually, for the dev server you can likely get debugging and possibly break points by creating a JavaScript Debug instance pointing at http://localhost:30001/
IE the URL of the dev server.
I don't believe so, re: normal.
Fair enough. I think I can swap between hot reload and debugging capabilities based on my needs while working on the module 🙂
Yeah. I almost never get to use the dev server as that is for end developers. When working on TRL itself it's all Rollup / production builds. So, you guys get to use the dev server the most.
@mleahy apologize if this is a discussion for a better place, like dev-lounge maybe? Maybe this is a stupid question but is it just me or I feel like the application window provided by TyphonJS are slightly more smooth when they are dragged around compared to the Foundry default implementation?
You should install
essential-svelte-esm and check out the Position (App) demo and the other demos too! TRL has a lot of optimizations over core for the UI. You have full orthographic 3D control + really fast tweening / easing animation in addition to GSAP control / timeline support for app windows and a lot more. There has been an inefficiency in the Foundry core code since day 1 that causes the core App v1 UI to be blocky / inconsistent. If I was on better terms w/ the core team I'd tell them how to fix it. It actually involves removing poor / inefficient code. Heh, that is a complex nut to crack; I do hope to have some feedback / input on the App v2 API, but so far I've made ~2 attempts to start a conversation through Cody and rebuffed / told not now each time.I guess they have different roadmap. Fair enough. Then it wasn't just my impression. I tried the essential demo. That's why I decided to go with typhon directly as it feels way easier to integrate that way 🙂
No... It's 12 lines of code that is the wrong code. Replacement is 6 lines w/ the right approach. Simple fix. Core App v1 API could be just as smooth.
Feels strange. Could it be that there might be some sideeffects and they want to be sure they have the time to react on that? Big guesses from my side cause I'm not entirely sure about their way of working.
Nope... Just a misunderstanding of how things work. My assumption is that Atro started w/ Pixi then tried to apply some improper gating on event handling / not understanding how the browser works efficiently. No side effects. It is a challenging topic as I've been sitting on this for nearly two years. 😮
I see. I never got close enough to the concept of performance connected to web dev/env. Sounds fascinating tho.
Yeah, I did a ton of performance analysis on the TRL position / animation system as well optimizing it for the most efficient browser approach that minimizes layout thrashing in respect to moving elements. The built in animation capabilities of TRL is about 1/3 faster than GSAP, but a little more limited than what GSAP actually does, so if you need animation of all style properties you use GSAP otherwise the built-in tweening to TRL is even faster.
I must say i was already a bit sad when I discovered ( 2 years ago ) that foundry didn't pick a modern ui framework.
Maybe it's good cause it gives more space but on the other hand mods are all over the place with different tecnique/lib.
To be fair JQuery / Handlebars was the right tech at the time that Foundry got started in the '17 / '18 timeframe / IE early exploration days. It was relatively easy to implement and a widely known approach. The other UI frameworks at the time (React / early Vue) would have been mistakes / lock in that would not have been ideal for what Foundry is as things go. Foundry has symptoms of a single dev being overextended in the amount of code that was required to make it all go where in this kind of situation eventually "good enough" solutions seep in...
I have made attempts to open a line of communication after v10 and v11 (after release a couple of months ago). I have 3 or 4 architecture points of view that would make App v2 great, but if they are not interested so be it. It's not my responsibility at that point, but indeed I was kind of hoping that things could be discussed and perhaps there still might be a chance. I might reach out once more, but again not my responsibility.
Part of the problem is that critical feedback is not handled as well as it could be perhaps.
I wouldn't blame them to some extent. I can imagine the amount of other feedback they receive daily.
Starting with jquery/handlebars was for sure the correct way but I'm talking about 2021 at this point. Back then I tried to create some modules and, since I used a bit of React during that period ( very small amount ), I was a bit surprised about it, cause well, I'm not a web dev so I was expecting something more than just plain jquery.
So I guess there are pros/cons as usual.
I wouldn't blame them to some extent. I can imagine the amount of other feedback they receive daily.A little more going on there than just that. Human behavior is a hell of thing and in general programmers can be a plucky bunch. ;P The App v1 API while the right early solution also became an intractable / or too wide spread / tendrils reaching everywhere. Every new feature implemented w/ App v1 from core support requires a rewrite w/ App v2; whatever that might look like. It's a tough nut to crack / improve at this point and takes really strong architecture skills to pull things off smoothly. I'm not so sure things are going to go smoothly. Heh heh... Let's hope a homespun UI framework is not made; knock on wood! It's a 50 / 50 chance that the core team will try to make their own framework, but hopefully not.
oh god. No. I hope it's not gonna happen. I already had enough nightmare of custom gamedev solution related to UI framework. ( I'm working as a UI dev in the videogame industry )
I finally managed to start gearing up. And yes.. the hot reload is such a bless!