Open RafaelGB opened 1 year ago
I can now confirm that the unusual persistence of formula output has been fixed. Besides that, I've noticed another pattern which is probably related to this one.
For example:
function format_compact_date(date) {
if (!date) {
return "";
} else {
return date.toFormat("'<small>'MMM dd, yyyy'<hr/>'hh:mm a'</small>'");
}
}
results in an empty column. By console logging, I can see that for every cell, it runs multiple times, and recursively. So, the first proper formatted data from the first run get overwritten by subsequent malformed output.
I've investigated this issue a little further. Say, I'm taking the current row as a formula input for the title field. Then I'm building the link using row.title
and row.__file__.path
and returning it.
What is happening is, upon returning, it is being assigned to row.title
, and it is triggering reactivity.
Oh! I have to test it
it should not be happening cause this line
but looks like there is some case that trigger the updateCell
action
If your formula returns a different result each time (milisecs on time) will trigger it for sure
If your formula returns a different result each time (milisecs on time) will trigger it for sure
Yes. Actually, I can work around it by getting the data from row.__note__
instead of the top-level. But that is not how it should be if we consider the doc's example. Even the date formatting examples won't work in the current state.
If your formula returns a different result each time (milisecs on time) will trigger it for sure
Yes. Actually, I can work around it by getting the data from
row.__note__
instead of the top-level. But that is not how it should be if we consider the doc's example. Even the date formatting examples won't work in the current state.
I forgot to mention, there is no external cause like millisecs but this recurring call. I'm still stuck at v3.1.3 for this only.
Wikilinks in simplest form works. But wikilinks with custom text don't.
Originally posted by @uroybd in https://github.com/RafaelGB/obsidian-db-folder/issues/688#issuecomment-1377800785