When called with file: TFile, the update() function now dispatches a transaction only for a markdown view whose file links to the specified TFile.
It turned out that the previous implementation made it impossible for the update() API function call to dispatch forceUpdateEffect properly. This was because forceUpdateEffect was defined like this:
This is not problematic at all for MathLinks itself, but for another plugin using the API, this creates a different forceUpdateEffect in its main.js as a result of bundling. As a result, this plugin dispatches forceUpdateEffect that is different from the original one, and this new state effect has no effect on the decorations MathLinks creates.
I fixed this by making forceUpdateEffect a member property of the MathLinks plugin instance. This way, we can always reference to the same forceUpdateEffect instance.
When called with
file: TFile
, theupdate()
function now dispatches a transaction only for a markdown view whose file links to the specified TFile.It turned out that the previous implementation made it impossible for the
update()
API function call to dispatchforceUpdateEffect
properly. This was becauseforceUpdateEffect
was defined like this:https://github.com/zhaoshenzhai/obsidian-mathlinks/blob/8869a1df04cdcd28c1c9376b7d156187d6a45b31/src/links/preview.ts#L60
This is not problematic at all for MathLinks itself, but for another plugin using the API, this creates a different
forceUpdateEffect
in itsmain.js
as a result of bundling. As a result, this plugin dispatchesforceUpdateEffect
that is different from the original one, and this new state effect has no effect on the decorations MathLinks creates.I fixed this by making
forceUpdateEffect
a member property of the MathLinks plugin instance. This way, we can always reference to the sameforceUpdateEffect
instance.https://github.com/zhaoshenzhai/obsidian-mathlinks/blob/cc7ef76939563ea1f9dfcb20ce32589045a99d62/src/main.ts#L17