blacksmithgu / obsidian-dataview

A data index and query language over Markdown files, for https://obsidian.md/.
https://blacksmithgu.github.io/obsidian-dataview/
MIT License
6.64k stars 394 forks source link

Bug report #2300

Open holroy opened 3 months ago

holroy commented 3 months ago

What happened?

Using Obsidian 1.5.12 and Dataview 0.5.66, it seems like dv.view() fails to render in live preview, but they're working just as normal in reading mode. This is tested in the Sandbox vault with no other plugins installed on Mac Os Catalina. It just shows the - indicator, and no error messages.

DQL

`$= await dv.view("js/test") `

JS

// in the file "js/test.js"

dv.header(2, "test")

Dataview Version

0.5.66

Obsidian Version

Present in 1.5.11 and 1.5.12

OS

MacOS

GottZ commented 3 months ago

can confirm. inline seems to be broken somewhat.

pierremouchan commented 3 months ago

For me, the issue was coming from the latest iconize version, I had to disable the plugin to make them work again.

GottZ commented 3 months ago

true but still. I'm not using iconize and have noticed a hard to reproduce related bug with inline queries.

holroy commented 3 months ago

In my case it triggers immediately when I add await ... in front of the dv.view() called. So I guess it's related to some asynchronous issue. And no I don't have Iconize plugin installed, so that is not part of my use case. (In either case, I triggered this bug in the Sandbox vault with no other plugins except Dataview.

josephgarnier commented 3 months ago

I can confirm a similar bug that occurred recently. For my test, I disabled all community plugins, except Obsidian DataView.

When I write $= dv.list(dv.pages()), the Live Preview mode displays <Promise>, while a Reading mode works well.

holroy commented 3 months ago

@josephgarnier , neither dv.list() nor dv.pages() by themselves should produce a promise. What else do you do in that query?

In general whenever you get a <promise> return you'll need to add await in front of that call. In your case you might need to use Promise.all().

In any case a promise is not a bug, but when/if the result disappear after adding the await then that's a bug.

josephgarnier commented 3 months ago

@holroy Just to check, I've just tested a new vault with all default settings and only the "dataview" community plugin. As you can see on the screen below, the instruction $= dv.list(dv.pages()) is displayed <promise> in Live Preview mode only, whereas in Reading mode the instruction works. Furthermore, there are no errors in the console.

Live Preview mode : image

Reading mode : image

Now, with the $= await dv.list(dv.pages()) instruction, the display changes, but the result is not as expected: there is no list of files, only one item :

image

edit : actually, the problem persists even with all core plugins deactivated.

holroy commented 3 months ago

@josephgarnier , that is indeed very wrong. Something strange has happened in one of the last updates. Neither response is correct when in live preview did that query.

This surely needs more attention and investigation.

GottZ commented 3 months ago

tomorrow I'm back in my usual debug environment and will try to fix this.

holroy commented 3 months ago

Do you have any idea what causes this, @GottZ ?

GottZ commented 3 months ago

Increasing the compile target to es2022 might have broken code with bad structure. it also broke that server version check earlier.

I got confirmation from an obsidian employee, that es2022 is the correct target these days tho.

I suspect I'll have to do a little housekeeping and re-implenent a few pieces here and there to make sure the code is up to current standards.

holroy commented 3 months ago

In other words, the code is going to be unstable for a version of two while working out those kinks? This should then possibly have not been a minor version raise , aka from 0.5.65 to 0.5.66, but rather have gone to something like 0.6.0. This change has caused breakage in many vaults, without been given a proper warning.

This change, alongside with that strange(?) live preview changes/bug in #2216, have broken two of the main use cases in my personal vault so I'm having issues on how to proceed.

And I guess the tests should possibly be extended to catch either of these

AB1908 commented 3 months ago

@GottZ should we roll back to previous stable version while we explore fix in beta release?

holroy commented 3 months ago

@GottZ should we roll back to previous stable version while we explore fix in beta release?

If we go down that route, which I'm in favor of, should we then also include all the stuff related to #2216 since there isn't any easy fix to that issue, and since it's not very clear which issue was resolved introducing that code at all?