WHITESPINE
WHITESPINE
Explore posts from servers
TTyphonJS
Created by WHITESPINE on 8/22/2023 in #typhonjs-runtime
Bug: Multiple ProseMirror editors on same svelte component do not save properly
Simple reproduction in a foundry world with at least one actor defined:
<svelte:options accessors={true} />

<script>
import { ApplicationShell } from "#runtime/svelte/component/core";
import { TJSDocument } from "#runtime/svelte/store/fvtt/document";
import { TJSProseMirror } from "#standard/component";

export let elementRoot;

let actor = new TJSDocument(game.actors.contents[0]);
let base_options = {
document: $actor,
fieldName: "name",
collaborate: true,
button: false,
editable: true,
initialSelection: "start",
};
</script>

<ApplicationShell bind:elementRoot>
<main>
<h1>Basic application</h1>
<span>{$actor.name}</span>
<TJSProseMirror options={base_options} />
<TJSProseMirror options={base_options} />
</main>
</ApplicationShell>

<style lang="scss">
main {
text-align: center;
display: flex;
flex-direction: column;
}
</style>
<svelte:options accessors={true} />

<script>
import { ApplicationShell } from "#runtime/svelte/component/core";
import { TJSDocument } from "#runtime/svelte/store/fvtt/document";
import { TJSProseMirror } from "#standard/component";

export let elementRoot;

let actor = new TJSDocument(game.actors.contents[0]);
let base_options = {
document: $actor,
fieldName: "name",
collaborate: true,
button: false,
editable: true,
initialSelection: "start",
};
</script>

<ApplicationShell bind:elementRoot>
<main>
<h1>Basic application</h1>
<span>{$actor.name}</span>
<TJSProseMirror options={base_options} />
<TJSProseMirror options={base_options} />
</main>
</ApplicationShell>

<style lang="scss">
main {
text-align: center;
display: flex;
flex-direction: column;
}
</style>
The top editor save button will do nothing. In general, it seems like only the last editor's save button actually works. When the components are unmounted, save works normally. This issue persists even if the editors are targeting different fieldNames.
25 replies
TTyphonJS
Created by WHITESPINE on 8/5/2023 in #typhonjs-runtime
TJSApplication Character Sheet odd behavior with unlinked tokens
Has anyone else experienced weird when using a TJSApplication as a character sheet with unlinked tokens? In my system, updating the base actor attempts to render the actor sheet for every token on the scene, regardless of whether that token's sheet was open previously. Every token whose sheet hasn't been rendered yet, will cause a fairly predictable "TypeError: An error occurred while rendering TJSDocSheet 45. this._element is null" - the sheet isn't mounted anywhere, so big surprise there. All other sheets will be made visible simultaneously. I think the SvelteApplication _render is missing the following check from foundry.js:
// Applications which are not currently rendered must be forced
if ( !force && (this._state <= states.NONE) ) return;
// Applications which are not currently rendered must be forced
if ( !force && (this._state <= states.NONE) ) return;
Which requires force=true to summon a closed sheet, as foundry seems like it will frequently render with force=false as a way to update any open sheets. Without this check, any of these "update" renders will cause undesired behavior.
10 replies
TTyphonJS
Created by WHITESPINE on 8/3/2023 in #typhonjs-runtime
TJSDocumentCollection best practices?
Hi! I've got a little component I'm using whose purpose is basically to just show a tiny preview of a resolved actor UUID. However, I want it to "short-circuit" (really more like long circuit) so that it grabs a world actor with the same name first, so repeated drag-drops of the same actor onto a scene doesn't infinitely duplicate... TL;DR: I need to be reactive on game.actors, and to do so was going to use a TJSDocumentCollection. Now for my actual ask. Within my component I have the following code.
<script>
import { TJSDocumentCollection } from "#runtime/svelte/store/fvtt/document";

// A summon. Though this might be an odd choice, explicitly NOT a tjs document!
export let uuid;

const world_actors = new TJSDocumentCollection(game.actors);

/// ... Blah blah blah
$: foo = $world_actors.find(x => x.name == my_resolved_actor.name);
</script>
<script>
import { TJSDocumentCollection } from "#runtime/svelte/store/fvtt/document";

// A summon. Though this might be an odd choice, explicitly NOT a tjs document!
export let uuid;

const world_actors = new TJSDocumentCollection(game.actors);

/// ... Blah blah blah
$: foo = $world_actors.find(x => x.name == my_resolved_actor.name);
</script>
The actual logic is more or less irrelevant. My main question is, with the knowledge that this component is instantiated fairly frequently and multiple times, is it ok to just make a new TJSDocumentCollection each time? Is there any special reason to make one once and reuse it multiple times (e.x. setup/teardown costs?).
2 replies
TTyphonJS
Created by WHITESPINE on 7/24/2023 in #typhonjs-runtime
Uncaught TypeError: $storeElementRoot is undefined
Hi! Encountering the following error when trying to resize an application based on a TJSApplicationShell. Exception:
Uncaught TypeError: $storeElementRoot is undefined
onResizePointerDown ResizableHandle.svelte:128
resizeDown ResizableHandle.svelte:71
activateListeners ResizableHandle.svelte:82
resizable ResizableHandle.svelte:109
Uncaught TypeError: $storeElementRoot is undefined
onResizePointerDown ResizableHandle.svelte:128
resizeDown ResizableHandle.svelte:71
activateListeners ResizableHandle.svelte:82
resizable ResizableHandle.svelte:109
18 replies
Migrating to DataModels - how to get data pre `cleanData`?
Hello. In the lancer system, we have some old fields in our Actor/Item models what predate the existence of UUIDs - they instead used a "RegRef" structure to achieve basically the same thing as a UUID now does. For context, a regref example:
{
id: "B1stOACZSDZAJLA7",
fallback_lid: "dep_ms_pattern_a_smoke_charges_smoke_mine",
type: "deployable",
reg_name: "game"
}
{
id: "B1stOACZSDZAJLA7",
fallback_lid: "dep_ms_pattern_a_smoke_charges_smoke_mine",
type: "deployable",
reg_name: "game"
}
Going forward, we'd prefer these just be a UUID string represented via a slightly modified StringField. The issue we are running into, though, is that it is difficult to migrate this data considering that the _source data of all actors is being modified via the DataModel._initializeSource -> BaseActor._initializeSource -> DataModel.cleanData, which destroys the above object and replaces it with "[object Object]". I tried accessing them via game.actors._source but it appears that the transformations in cleanData affect that data too. Is there a good way around this? Thanks
14 replies