Does Dataview inline DQL resolve Promises?

[Lenny]

Hello,
I’m writing a project based on existing code not written by me and I’m quite puzzled by why this work because I think it shouldn’t

In a note there is an inline dv field whose value is:

my_view:: `$=dv.view("example", {file: "Hello there"})`

and later, on the note’s body the view is execute with the following line

=this.my_view

This puzzled me for two reason:

1. I do have a folder named example that contains a file named view.js
   • This folder is NOT located at the vault root, it’s stored under a _views folder.
   • According to the documentation the first parameter of dv.view should be the full path where the file or folder containing the js code is.

Question 1: why does this code code work even tough the full path of the js file is not specified?
The correct one should be dv.view("_views/example", {file: "Hello there"}).

HINT: I’m using obsidian-modules, can it be that this plugin is exposing the folders under _views as modules globally available to any dataviewjs query into the entire vault?

2. The documentation also shows that dv.view should be awaited and used like so: await dv.view("views/custom", { arg1: ..., arg2: ... });
   • In my case the code is stored in an inline field as an inline js query (because of the $=...)
   • Then this field is invoked via an inline DQL with =this.my_view

Question 2: why does this work without any await ?
Question 3: why the dv.view expression is saved as an inline query and assigned to my_view? What would be the reasoning here?

Also noticed that if I use a dataviewjs code block in the notes’s body like so, it produces the same result. In this case the await is required, without it it just produces a Promise object (as it seems logic).

//dataviewjs
await dv.view("example", {file: "Hello there"}) 

Question 2.1: So does it means that the inline DQL =this.my_view automatically resolve the promise?
I couldn’t find anything on dv documentation about promises.

[holroy]

You’ve entered into a finicky, to say the least, area of coding. When javascript encounters async functions needing to be awaited they’ll return promises, and in general you should use await in front of such a call to ensure proper handling.

Somewhat simplified what happens is that javascript push the execution of async code onto a queue, and when the engine decides it needs to it executes stuff from the queue. Typically at the end of any given function it might check this queue. This means that if you don’t await stuff it can sometimes execute the async code before you’re able to see the promise, and everything is seemingly alright.

This might be a little unprecise, the gist of it is that you should always use await in front of async code, and not rely on “luck”/“chance” to resolve the promises for you. This holds true even though using inline queries will often trigger a possibility for the engine to execute the async code befire you’re able to see it…

As to why they use inline fields to store the query for later retrieval I can only guess is either due to a misbelief that the field stores the query result and not the query, or possibly to save some typing when they want to use the query further down run the note.