SyrinControl & Svelte...

I gather there is a bit to discuss... πŸ˜„
14 Replies
Vauxs
Vauxsβ€’12mo ago
I got roped into this and I shall now rope you into it
TyphonJS (Michael)
TyphonJS (Michael)β€’12mo ago
Most excellent.. I think @frondeus will be along shortly. πŸ˜„
frondeus
frondeusβ€’12mo ago
Of course πŸ™‚
TyphonJS (Michael)
TyphonJS (Michael)β€’12mo ago
It's definitely an interesting situation particularly w/ the lack of ongoing community types support that adds a potential bit of extra pinch to forward oriented maintenance with what you have created.
frondeus
frondeusβ€’12mo ago
Yeah, my codebase needs a solid refactor, thats for sure. I also managed to abuse $: operator quite a lot and that is very powerful yet very dangerous tool πŸ˜„ The reactivity one in Svelte Professionally im more a backend developer than a frontend guy : ) So coming from Rust world, types sounded like a good idea back then when I started working on this module
Vauxs
Vauxsβ€’12mo ago
Oh woe those who use TypeScript inside a non-TS environment
TyphonJS (Michael)
TyphonJS (Michael)β€’12mo ago
Absolutely. I haven't taken too in depth of a look at the codebase, but did see several things that can benefit from using TRL / my UI framework. There is a solid bridge to mounting Svelte components / controlling the app lifecycle vs adhoc mounting in activateListeners. Many other cool things as well as in TRL the entire "application shell" is Svelte based and out of the box HMR is supported w/ Vite, so a more pleasant and instantaneous dev loop is possible w/ Svelte on Foundry. Another possible thing to look out for which can happen quite easily is "prop drilling" where you pass around props from the top to bottom components. You'll find that in a fair amount of 3rd party Svelte components and is an easy thing to do when you first start using Svelte. This kind of "anti-pattern" affects Vue / React too. I'd have to look at the codebase in more detail though to see if that is present. I do create types for TRL and the next release upcoming soon really strengthens that a lot, but the missing bridge to Foundry still remains.
frondeus
frondeusβ€’12mo ago
TRL looks interesting πŸ™‚
TyphonJS (Michael)
TyphonJS (Michael)β€’12mo ago
Svelte is a great tech to choose for Foundry dev IMHO for many of the reasons that you mention in the Syrinscape forum post. It just will be a bit harder to find folks that can help contribute that also are active in the Foundry 3rd party dev scene. I'm lucky to be able to work on dev efforts full time right now, but am pulling back for the time being on direct package dev spending all of my time on the UI framework. I justify all this work as I'm expanding the UI framework / desktop app like UI toolkit beyond Foundry to reach the entire Svelte dev community. Foundry has been a great environment to move all that forward. I have been working on TRL full time+ since Oct '21, so it is well onto the path to maturity. Don't mind the "alpha semver" as I am rather conservative on that front. I'm considering things reaching "beta" when I have everything fully working on top of SvelteKit / open Svelte dev & Foundry. The general expectation that this will be reached first half of next year. TRL has been rock solid though on Foundry for quite some time. Re: Typescript and how to move forward w/ the SyrinControl codebase. It probably makes sense to convert to ES Modules / ESM. The nice thing is that there is reasonable intellisense support in various IDEs for Foundry. Some are easier to setup than others. WebStorm for instance is straightforward and reliable. Using JSDoc + types in comments is a viable way forward for type safety. For library / framework efforts like TRL I have developed tooling to generate TS declarations from ESM + JSDoc source code that works well. This is how I ship types for TRL and am generating API docs. The next release that is incoming shortly finally provides comprehensive API docs which is nice. For an end package like SyrinControl JSDoc does work out nicely when you hook up the IDE to the underlying JSDoc types in Foundry. All the type information that you have in Typescript will transition to JSDoc / @param tags.
frondeus
frondeusβ€’12mo ago
I agree, probably JSDoc would fit better than TS. However that means complete rewrite since I used TSysinge - microsoft's dependency injection framework for typescript. I tried to separate logic from UI and from API calls for better unit testing πŸ™‚ Of course I bet there is cleaner alternative to that problem. Anyway, I looked at the TRS example anc I like what I see. It is more focused on the dialog windows, am I correct?
TyphonJS (Michael)
TyphonJS (Michael)β€’12mo ago
TRL does cover quite a bit of territory, but does have strong support for complete Svelte based control of the app windows that is more efficient than core in performance and capabilities. IE you can do full matrix transforms on app windows. Re: tsyringe. It does look like the dependency injection usage is mainly for your game wrapper FVTTGame which all of that can go away in an ESM version as you can just access game directly without the fuss of the strict version of the community types. I think you should definitely wait until I get the next TRL release out especially since it comes w/ API docs. Hopefully ~2 weeks or less for that. It's no small amount of work though converting what you have to ESM. This is a good recent article discussing JSDoc and TS integration: https://dev.to/samuel-braun/boost-your-javascript-with-jsdoc-typing-3hb3 You'll probably hear me mention import types and this is something modern IDEs allow in JSDoc via TS (also worth reviewing the rest of this page): https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html#import-types For anything that you can't conveniently type in JSDoc you can create a d.ts file and reference via import types.
yenbengreyarm
yenbengreyarmβ€’11mo ago
Wow! Just so you know I’ve no idea what you’re all talking about but it looks impressive! I’m glad that you’ve got a dialogue though. I’m back from holiday/vacation tonight so I’m going to contact Syrinscape just to touch on the point of financing something in their interest. Hello there folks, @frondeus @vauxs @mleahy It is with great sadness, that Syrinscape have written back to me and told me that they are not going to fund anything Foundry related and that it is up to folk to create their own modules to integrate with them. Another person on the forums has suggested paying a patron account for Frodeus and anyone who is helping them. I said that this would be in effect paying twice for Syrinscape when other sound providers are either free or you can add what they have got via core. It baffles me that Syrinscape said themselves that they met "lots" of people wanting the integration at conventions, and if they were to invest they would get more subscribers, yet won't commit to one of the most popular VTTs out there. I think due to this I am going to stop subbing Syrinscape and use a different method. Wavs and Oggs and Mp3s etc.... I am really sad about this, as I have been loyal to Syrinscape for so long now. 😦
frondeus
frondeusβ€’11mo ago
Recently I got a contribution to the Syrin Control and the guy was pleased with the codebase he found 😊 He might contribute in the future but that's it About the funding - I don't think patron account is not the solution. Sure it would be nice to get money from it but the point is - I won't be able to pay the bills and live only from the Patronite with the current playerbase Which means I of course won't quit my job And the problem is not money but time If Syrinscrpe does not want to invest in it then so be it I'm putting the effort in the project only when it's beneficial to my own campaign
TyphonJS (Michael)
TyphonJS (Michael)β€’11mo ago
And the problem is not money but time
Time is money as things go, but also important for sanities sake if you are a working professional. If you are a pro / solid developer you already know what your time / hourly rate / worth is as well. It is very hard to balance passion for a space like TTRPG in respect to VTTs. VTTs already are a niche of a niche and making plugins / integrations to a single VTT is niche^3, so not a profitable or easy thing to be involved with as there is a lopsided value proposition that flows upward to the platform and services one integrates. In other words the maxim "the platform always wins" is playing out here. I have the same general problem in respect to Foundry itself as while the Foundry team has courted content creators they have completely ignored setting up a well functioning store that could provide a possibility for sustainability for the 3rd party development community. No one is going to get rich making plugins for a VTT. I've given Foundry several years now to get their act together and wide leeway given the indie start, but they have over 10 employees now and albeit still a small company. At some point it's just negligence and while maybe not a "corporate sort of greed" still is a non-starter for continuing to send value upward with little in return. So, basically I definitely understand the sentiment and situation. I don't think Patreon is a good mechanism to fund high quality software development either. It's a nice alternative to throw a little extra cash to a creator you like, but a poor solution for software in general. I very much consider that for a platform to be truly successful it needs to provide more value than it captures for all parties involved and we are not seeing that in the TTRPG / VTT space.