Error in $doc.update()?
I'm not quite sure if I'm doing it wrong. The error I'm getting is:
Here's the component
Normally (e.g. in my system, as opposed to this module)
$doc.update()
just works for me. I haven't seen this _id
error before. It seems weird because update
is being called on $doc
, which is a TJSDocument
instance of the actor
, so it has the _id
already I would expect.6 Replies
Ahh.. nvm. The actor is in memory, so I need to use
updateSource()
not update()
You are also using
Timing.debounce
incorrectly.
It should be:
Timing.debounce
is a higher order function that returns a function with the specified debounce functionality around the callback / function specified as the first argument.I ended up with this:
The
$doc = $doc
– is needed to make the mod
value (last line of the template) reactive (from https://learn.svelte.dev/tutorial/updating-arrays-and-objects)
It feels inelegant. Is there a better way to facilitate nested reactivity when using $doc.update()
or $doc.updateSource()
?Presently, no because
$doc.updateSource
doesn't trigger the DB update response / callbacks. However, I'll look into adding an updateSource
method directly to TJSDocument
which will invoke the underlying updateSource
of any wrapped core document, but will also trigger reactivity for in memory changes. In this case you'll drop the $
and it will just be doc.updateSource(...)
. I might also add a correponding update
method to TJSDocument
.
So, in 0.2.0
there should be a way to automatically trigger reactivity w/ TJSDocument for in memory usage.Is there a new way to do this now? I think my above code no longer works in 0.3.0. I've mentioned this in my forum post about the upgrade but this might be a better place to discuss it.
I can't help wondering if svelte 5 runes wouldn't be useful here.
Tried a few things... this seems to work:
`
I can't really debug your code. First as always by using PUG this provides a barrier to sight-read your code to see any obvious mistakes. The code you write may have many bugs / inefficiencies in it that you are unaware of.. For instance this looks wrong:
Particularly this
on:input!="{updateDebounce(ability[1].abbreviation, event)}")
It looks like you are invoking once the function instead of assigning an arrow function like on:input={(event) => updateDebounce(/* stuff */)}
This is not reactive:
TRL likely is not broken, but your code may easily have one or more problems that you are generally unaware of how the interactions are or are not occuring.
Learning to debug your own code is important. Divide and conquer is generally how you should approach this process. Verify each half / step and ensure that you are getting the values you expect before looking at the other half of code.