You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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?
The text was updated successfully, but these errors were encountered:
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 myshared-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 publishReactApplicationV2Mixin
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):
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?
The text was updated successfully, but these errors were encountered: