Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finalize ReactApplicationV2Mixin when V12 testing releases begin #761

Open
n3dst4 opened this issue Apr 14, 2024 · 0 comments
Open

Finalize ReactApplicationV2Mixin when V12 testing releases begin #761

n3dst4 opened this issue Apr 14, 2024 · 0 comments
Assignees
Labels
bts 😇 BTS magic

Comments

@n3dst4
Copy link
Collaborator

n3dst4 commented Apr 14, 2024

There's a lot up in the air with ApplicationV2 rn, so return to this when some of the dust has settled.

Personally, I won't be using ApplicationV2 for INVESTIGATOR until V13 comes along and I can safely drop support for V11 (I have always tried to support the previous version of Foundry for people who are stuck using it for other reasons, i.e. a favourite module hasn't updated.)

That said, if I develop any new modules before that, I'd probably start with V12 compatibility and use ApplicationV2.

I'll be consuming ReactApplicationV2Mixin via my shared-fvtt-bits repo, but while that is publiuc, it's not really intended for third parties to use directly, so it would be nice to publish ReactApplicationV2Mixin for others to use.

The easiest way would be just as a code snippet somewhere. Could even be a link back to shared-fvtt-bits.

The best way (to me) is as an npm package. If I do publish it at all, that's my favoured approach.

Both of these assume that the consumer is using a build step and a bundler.

The third way is as a Foundry module, which could incorporate React itself. I'm in two minds about that. On the one hand, it would make React very accessible for people who are just smashing JS together with no build step or anything. On the other hand, is there anyone who uses React who isn't comfortable introducing a build step?

Inter-module dependencies feel fraught. This comment from Matt is pertinent (https://discord.com/channels/170995199584108546/1209623497664364614/1228401516038062180):

The trickier bit with having a Vue dependency is that it's tough to depend on a module for systems in particular. I originally used the VuePort module when we transitioned 13th Age to Vue and even with extra checks to ensure the module was enabled, it was significant pain point for our users. Things got a lot smoother when I rolled my own Vue solution directly into the system.

I feel that. If I publish as a module, am I now on the hook for supporting people having dependency issues? Supporting people who are using this code in a way which is completely alien and weird to me?

@n3dst4 n3dst4 converted this from a draft issue Apr 14, 2024
@n3dst4 n3dst4 self-assigned this Apr 14, 2024
@n3dst4 n3dst4 added bts 😇 BTS magic and removed enhancement ✨ labels May 11, 2024
@n3dst4 n3dst4 moved this from Todo to In Progress in Lumphammer Public ☀️ Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bts 😇 BTS magic
Projects
None yet
Development

No branches or pull requests

1 participant