Organizing Source Constants | Foundry VTT | Page 1

patent hinge Jul 7, 2022, 5:22 PM

#

@small hearth We can continue the discussion in this thread when you are available.

small hearth Jul 8, 2022, 7:52 PM

#

@patent hinge Yesterday didn't work out for me. If you have time to share your approach, let me know.

patent hinge Jul 8, 2022, 9:48 PM

#

small hearth <@595110782241603585> Yesterday didn't work out for me. If you have time to sha...

Perhaps you can let me know where on the programming journey you fall. How much experience do you have w/ ES Modules and what IDE you are using? Have you used JSDoc for writing comments?

small hearth Jul 8, 2022, 9:48 PM

#

Heh. My "IDE" is tmux and Vim. :-)

patent hinge Jul 8, 2022, 9:49 PM

#

Yeah.. That is "less than ideal" per se for many of the features you get in an IDE w/ Javascript support.

small hearth Jul 8, 2022, 9:50 PM

#

As far as the programming journey, I used to code C and Perl. These days, often Ruby. I started coding Javascript when Netscape Navigator was still the main target, but I'm way out of date on it.

#

When I started looking at module code and saw the "class" keyword, I was pretty confused. Used to prototypes in JS.

#

As a programmer generally, I think I'm pretty solid. I'm somewhat out of my element in this particular domain, but I'll adapt.

patent hinge Jul 8, 2022, 10:00 PM

#

For sure re: adapt. Yeah.. The nice thing about Foundry is that the core platform itself is built on modern JS / ES Modules and uses recent functionality. JS has been going through a "renaissance" period starting in 2015 w/ the introduction of "ES6". This is where the "class" syntactic sugar and such is coming from, but more or less each year there are new features released for ES Modules / modern JS. Foundry itself uses many recent features and this makes it nice as 3rd party developers as Foundry users must use an updated browser. By extension as 3rd party devs we can also use modern JS without the need for transformation to older JS standards like ES5.

The most latest ES2022 yearly standard introduces private variables for instance.

ES Modules with the "class" keywords and such is still a prototype based arrangement under the hood. A good website to that goes over modern JS / ES Modules is here: https://javascript.info/

small hearth Jul 8, 2022, 10:02 PM

#

I like how that site is laid out. I'll definitely look through that. Pleased to hear about the general orientation towards "modern"; backward compatibility with browsers is a PITA, and not worth it with something like this.

patent hinge Jul 8, 2022, 10:05 PM

#

Absolutely. Between 2015 and ~2019 you could write your code w/ the modern ES Module (ESM) standards, but pretty much had to use Babel or a tool to transform modern ESM to ES5 to run on browsers and Node, but since 2019 support in Node and browsers has increased tremendously so transformation steps aren't needed as much though you may opt to include some lighter transformation if you are using the absolute latest / IE this years new standards in code.

#

With creating a constants file and ESM in general getting a good feel for the import / export semantics is helpful. A link to the page in that previous web site regarding this area of ESM: https://javascript.info/import-export

small hearth Jul 8, 2022, 10:09 PM

#

Heh... looking through the previous page on modules. "For a long time, JavaScript existed without a language-level module syntax. That wasn’t a problem, because initially scripts were small and simple, so there was no need."

#

Bullshit. :-)

#

But, better late than never.

patent hinge Jul 8, 2022, 10:15 PM

#

There were and still are, but far less used external module standards that appeared around 2009. CommonJS / AMD are two such external standards. ESM introduced the official built in JS standard w/ ES6 circa 2016. Node.js is still a hotbed so to speak for CommonJS, but has solid built in ESM support since ~2019 / Node v12.

small hearth Jul 8, 2022, 10:17 PM

#

The standard module stuff looks very sensible, so far.

patent hinge Jul 8, 2022, 10:18 PM

#

But yeah.. It's good to read up on modern IDEs as well: https://javascript.info/code-editors

The majority of Foundry devs use VSCode as it's free, but I highly recommend WebStorm; in the grand scope of things it's rather solid and much easier to configure for ESM in relation to Foundry than VSCode. I believe the Foundry core team also uses WebStorm. If you have enough open source contributions as referenced in a Github profile over the last year you can get a free WebStorm OSS license.

#

You can use vim, but there likely aren't plugins that are updated for ESM / modern "intellisense" or if there are it likely is hit or miss.

small hearth Jul 8, 2022, 10:19 PM

#

Honestly, I'm very unlikely to give up Vim.

patent hinge Jul 8, 2022, 10:20 PM

#

And that will be something you'll just have to deal with then as it may not support the same things you get out of a modern IDE.

small hearth Jul 8, 2022, 10:20 PM

#

Yeah, I get that.

patent hinge Jul 8, 2022, 10:23 PM

#

Just like the modules quote the website linked , "IE so there was no need" is a similar sentiment that could be applied to code editor of choice. If you are working on a simple project vim is probably fine, but you get a lot more out of a modern IDE and there is good support in modern IDEs to link the Foundry source code to your project code, JSDoc / intellisense, types / Typescript support, and easy integration with package managers like Node / NPM to install additional developer tooling along with live debugging capabilities that you don't have w/ vim.

#

So it's kind of you don't know what you are missing if you don't try it out scenario.

small hearth Jul 8, 2022, 10:26 PM

#

I'm not opposed to checking things out. It's going to be very hard to match the value I get out of an environment I've configured for years and mastered. As far as debugging, I generally fully understand every thing I write, and I scarcely write more than a few lines without testing.

#

What I'd particularly like is to be able to run code in a shell, and automate tests.

#

I understand the danger in being stubborn here.

patent hinge Jul 8, 2022, 10:29 PM

#

That is not the case w/ Foundry as you are running on top of a relatively complex and shared environment; IE other 3rd party code from game systems to other modules.

You can't run tests from a shell w/ Foundry and there should be some threads around discussing various solutions, but a headless browser test solution is the way to go more or less.

small hearth Jul 8, 2022, 10:29 PM

#

Yeah, we're deeply embedded within a complex environment.

patent hinge Jul 8, 2022, 10:30 PM

#

IE re: debugging.. It's super simple to hook up w/ WebStorm and you can set break points in your code and Foundry code and have full context clicking from your code through to Foundry code, so there is quite a bit of an advantage; in this department WebStorm is much easier to configure out of the box than VSCode.

small hearth Jul 8, 2022, 10:33 PM

#

I'll check it out.

patent hinge Jul 8, 2022, 10:37 PM

#

Nonetheless as far as constants go as mentioned what I do is create a single file at the top level of the project constants.js. You can then export individual objects that group categories of constants together. I develop / maintain Forien's Quest Log which is a complex module based on the Foundry core API...

The constants file is located here: https://github.com/League-of-Foundry-Developers/foundryvtt-forien-quest-log/blob/master/src/model/constants.js

With FQL I don't use any build tools, so the extra tricks that I use for an even bit more modern approach don't apply.

You can see imports of various constants objects here: https://github.com/League-of-Foundry-Developers/foundryvtt-forien-quest-log/blob/master/src/control/FQLHooks.js#L14

I separate all hook registration w/ Foundry into a separate file.

I separate the module settings registrations into a separate file as well (you can see the constants imports referenced at the top):
https://github.com/League-of-Foundry-Developers/foundryvtt-forien-quest-log/blob/master/src/ModuleSettings.js

#

In regard to FQL it is structured in the classic MVC / model / view / control pattern. The MVC pattern works adequately for small to medium sized projects which most are for 3rd party dev of modules on Foundry.

small hearth Jul 8, 2022, 10:42 PM

#

Yeah, this makes sense. I was thinking to put my values in an external JSON file, but I wasn't sure how to go about importing them. What you're doing will do the trick.

patent hinge Jul 8, 2022, 10:45 PM

#

In a modern IDE you get "intellisense" and easily being able to jump between files in your project. The IDE understands JSDoc comments / typing and provides type support out of the box.

small hearth Jul 8, 2022, 10:47 PM

#

Heh... in tmux, I don't so much jump between files as just look at them.

#

Often I have most of the files in a project open at once. All the related files in different panes, and if there are a lot, different windows grouping panes.

patent hinge Jul 8, 2022, 10:50 PM

#

Well here is an example w/ the same settings registration code in WebStorm that shows the Foundry code linked. You get intellisense when hovering over Foundry code and can easily jump into the actual Foundry code. In this case I clicked on the game.settings.register function:

small hearth Jul 8, 2022, 10:50 PM

#

Which is pretty much how my "GUI" works... I run i3, a tiling window manger on Linux.

#

I'm not arguing against this; as I said, I'll definitely check it out. Being closed-minded certainly isn't a virtue.

patent hinge Jul 8, 2022, 10:54 PM

#

It sounds like there is a whole world of modern tooling to get a potential grasp on beyond IDEs as well that you quite possibly haven't been introduced to yet; more or less at top of the rabbit hole w/ just modern IDEs, etc.

small hearth Jul 8, 2022, 10:54 PM

#

I think what isn't necessarily obvious is just how sophisticated shell-based tools are. There's a reason people who learn them don't like to give them up.

patent hinge Jul 8, 2022, 10:55 PM

#

I certainly recommend getting familiar w/ Node & NPM for configuring projects and retrieving extra developer tooling from it. You can of course use Node / NPM command line.

#

A lot of modern JS build tooling revolves around the concept of bundlers these days. Rollup being what I currently use, but I'm switching to Vite soon. This tooling is installed from NPM and you can use it command line, but also IDEs have integration as well, but that is more convenience.

#

There are plugins for these bundlers that allows you to configure particular aspects that ESM doesn't support out of the box. You mentioned how do I import a JSON file. In stock ESM you can't, but with a plugin to a bundler you can along w/ many other powerful tooling integrations. In the older Rollup module demo repo I put out when I first started using Foundry a couple of years ago I have an example of importing a JSON file. It also has examples of using a plugin to substitute strings in code during the build process.

This will cover some of the essential ideas on what a modern build process brings to the table:
https://github.com/typhonjs-fvtt-scratch/demo-rollup-module

#Organizing Source Constants