Some of my ideas for future versions

[holroy]

Here I'm going to mention some of the larger ideas I would like to implement at some time in the feature. Thinking of it as a possible roadmap, where nothing is set in stone. It's more of a scratchpad where I mention various thoughts I've had, and there is no particular order in how the ideas is going to come (or be implemented). If you want to contribute/comment on either of the ideas, be sure to reply to that specific feature comment.

• Code block paramters
• User functions
• Access to tables
• QoL functions
• Extended tasks functions
• Locale support in date functions
• Extend canvas functionality (primarily discussed in What should we do with canvases? #2534)

[holroy]

Code block parameters

In the https://github.com/mayurankv/Obsidian-Code-Styler plugin, they're using various text on the leading code block fence to change parameters for this block. I would like to have the same kind of functionality for Dataview. Some parameters I would like to add parameters for:

• Showing/hiding of subtasks
• Adding cssclasses to the query
• Showing/hiding of the header row
• (Possibly set a flag to allow for tables to be read in this particular query)
• Enabling/disabling/change of the refresh interval for this query in particular
• Adding a persistence flag, which would render the output as static text in the result file (See also "Burning out" dataviews #42 and Future-Proofing and Dataview #1026)

See also #1741 ( #1779 )

[holroy]

User functions

Like in Templater I would like to have the possibility to add user functions. I imagine these being available for both DQL and dvjs queries (if possible), with some prefix. So say you defined a myFunction, you could use it dvu.myFunction or similar.

I'm still debating with myself whether I would want to define such functions within a dedicated folder using pure javascript, or whether it should be possible to define within a normal markdown file, and possibly allow for pure DQL functions. For the latter I'm not sure how that would allow for input parameters though. (Could possible be defined in the code block parameters? )

I do kind of liking the notion of defining them in ordinary markdown files, since that could allow for easy documentation of the function (and we could share the note with your custom functions), or in-place functions related to that particular page having special needs. It could however be slightly harder to maintain possibly, if care is not taken

[holroy]

Access to tables?

I'm also wanting to have some sort of access to existing tables, but this is could be a major thing, so I'm not sure how to address this in the current setup.

[holroy]

QoL functions

Various smaller functions I've been thinking about:

• range() to allow for generating a random range
• keys(), value() and entries() - Similar to the Object.keys() & co from Javascript. This would give ut access to nested objects within properties a lot nicer, and it would also allow us to separate out handling of the first/last elements of lists and so on
• defined() - Check whether that field is defined (and not only not null) in a given context
• firstValue() - Combines the operations of nonnull(listField.someField)[0], which would allow us to define fields in sub-lists, and easily reference them from the parent item
• zip() - Similar to the python function, where we can use it to join various arrays element on their respective indices. This would allow for various lists made just in the page context to be joined relative to their index. It would also allow for an easier way to make properties being either single values, or lists values, to conform into the list syntax using zip(propertyName). For the first variant, imagine having [book:: First book] written by [author:: My author], the [book:: Second book] this one written by [author:: Another author] in a note, then zip(book, author) would produce the [ [book: "First book", author: "My author"], [book: "Second book", author: "Another author"] ] array with all the information in that one array

[holroy]

Extended task functions

Not sure if these should make into the repository as ordinary functions, or if they should rather be presented as example functions related to how one could handle tasks within tables, but I've been contemplating on something like the following functions:

• taskLink() - Which would produce a link to the specific task within that file. It would take a single task as input, and use the position element to generate a link similar to how tasks are linked today within a TASK query. This functionality could possibly be extended to any object having a position object, especially I'm then thinking about an ordinary list item.
• changeStatus() - A function to change the status of the task, possibly with/without the addition of some date field. A few use cases for this would be to complete/toggle a task from within a table, and maybe to choose the status from a given list of status. The latter would then allow for defining various task sets like BuJo-tasks status, or an activity set of statuses, or similar user defined set of custom statuses
• clean() - A function where one easily could remove stuff like links, emoji-date-fields, inline fields, and/or tags. Currently it's somewhat easy to extract that information from the task text, but it's not as easy to clean/remove it from the original text. Using this one could then build a table where we split the task in columns having: the task status, a clean task text, tags, inline fields, emoji-date-fields in separate columns

[holroy]

Locale support in date functions

Being a Norwegian I sometimes encounter various issues related to how the locale is predefined as en-US (or something like that), which causes various effects across the boards. I'm also active in the forums, where it sometimes would be nice to present/test stuff in a given locale. Therefore I would like for most of the date functions to allow for an optional parameter to control the locale used within that context. This should then allow for better handling of converting local date format like "Mandag 1. oktober, 2027" (or similar local variants), or presenting them in a unified way.

Could possibly be related to #571

[holroy]

Extend canvas functionality

I believe some things needs to be done, but I'm not sure what. This is to be discussed in #2534