#document update cycle
1 messages · Page 1 of 1 (latest)
They don't, and I think the devs were hesitant to call it a bug rather than just undocumented behavior
Similarly but opposite-ly, using createEmbeddedDocuments does not call the Primary Document's preUpdate - onUpdate event cycle.
(I don't have opinions about this, I'm really just discovering and clarifying; thanks @slate ruin)
create and update instance methods all get funneled through the target document type's Document.createDocuments and Document.updateDocuments static methods, along with their corresponding _pre/_on instance methods. This is the case whether the target document is embedded or independent
so, e.g., actor.updateEmbeddedDocuments("Item", { ... }) will hit Item.updateDocuments, item._preUpdate, and item._onUpdate
actor.update({ items: [ ... ] }) will hit Actor.updateDocuments, actor._preUpdate, and actor._onUpdate--even if it had the same result as actor.createEmbeddedDocuments
relevant commentary: https://gitlab.com/foundrynet/foundryvtt/-/issues/5953#note_699098145
Oh man tokens are a topic i'm afraid to dive into yet. I've heard the stories. Big thanks, this makes sense.
So... stepping back into the ephemeral "recommendation seeking" aspect.
Is it fair to say it is "not recommended" to 'abuse' the Embedded Document creation/update aspect of updating a Primary Document as this 'bypasses' the normal event cycle for that embedded document?
You still have option of creating synthetic document (and get the events) and pass the data from that (doc.toObject()) to the bigger update, so it might be fine?
Tho I also feel the lack of preCreate is rather unexpected if not loudly documented (is it?)
it's documented here: https://foundryvtt.com/api/abstract.Document.html#_preCreate
Documentation for the client-side JavaScript API in Foundry Virtual Tabletop.
plus, I assume, any overrides thereof