Some thoughts on API access to Tasks features #1646
Replies: 8 comments 19 replies
-
currently, I see that the This is an internal data structure. Maybe it would be better to return some sort of Could do something like,
|
Beta Was this translation helpful? Give feedback.
-
Is there an issue for this? I'm curious to check it out ... |
Beta Was this translation helpful? Give feedback.
-
re: point 6.2.2, if someone ideates a solution for write-access whilst considering that there will be major changes to replace with datacore code, would that work? I was thinking about how end users (other plugin devs) would even desire write-access, i.e. what would be useful/convenient. and I think to an extent, the design of read-access seems related to write-access, and thinking at the same time about how both should work might be useful? |
Beta Was this translation helpful? Give feedback.
-
I found another request: added in the list above: |
Beta Was this translation helpful? Give feedback.
-
I think this is my lack of knowledge here on Ob things ... what are "Obsidian graphical classes"? |
Beta Was this translation helpful? Give feedback.
-
Related: from the Tasks 2.0.0 release note: 🌟 Added new public API to retrieve markdown string for a new task via the 'Add or edit task' modal - thanks |
Beta Was this translation helpful? Give feedback.
-
Hey, I think this needs to be approached like scripting - moving and letting the user do something is a lot more important than maintaining perfect forward compatibility foresight. Dataview, for example, doesn't care at all and just gives you the internal types, they're nice enough. It additionally exposes some utility functions like If there's interest in building a beta-version of the API that would expose querying (I'm mainly interested in FullCalendar integration so this is the most important feature for me), then I'm totally game. Would appreciate permission to nag over chat, though. |
Beta Was this translation helpful? Give feedback.
-
I am wondering if we could allow for reactive behavior on task updates. export interface TasksApiV1 {
// New stuff
subscribe(handler: (event: string, data: any) => void): void
// Old stuff
createTaskLineModal(): Promise<string>;
executeToggleTaskDoneCommand: (line: string, path: string) => string;
} With the new This would allow other plugins to add custom behavior for this plugin. Potentially, it removes the need for Also, any other plugin could store its state in const api = app.plugins.plugins['obsidian-tasks-plugin'].apiV1
// onCompletition support could become a plugin of its own
api.subscribe('taskToggle', (task: Task) => {
somehowDeteleTheLineFromMarkdown(task)
}) WDYT? |
Beta Was this translation helpful? Give feedback.
-
Tasks API integration - overview
This is a brain dump - and notes dump - of @claremacrae's notes on possible Tasks plugin API/facilities for integration with other plugins.
1 Existing Requests
2 What I feel Tasks offers
3 Plugins interested in integration
I've been keeping a canvas about the requests received...
Here is the source canvas file, for working links:
Tasks - Helping other plugin developers - version 1.canvas.txt - remove
.txt
extension to use4 Accessing the code - npm or
this.app.plugins.getPlugin
There's been a lot of discussion about whether to:
this.app.plugins.getPlugin("obsidian-tasks-plugin")
The conclusion is to start with the
this.app.plugins.getPlugin("obsidian-tasks-plugin")
route.5 Existing integration code - and examples
5.1 In main vault
5.1.1 Render methods exposed - undocumented
Example code:
5.1.2 Access to all the current tasks - undocumented
obsidian-tasks/main.ts at bf2ac0fb5a66abd899b477686d45c6e3969d4aa5 · obsidian-tasks-group/obsidian-tasks · GitHub
5.2 In Clare Macrae's fork
5.2.1 Running Tasks queries and accessing results
obsidian-tasks/main.ts at c302c57ae4a5ad2f1aa2d071c3d8565f24229e12 · claremacrae/obsidian-tasks · GitHub
Example of use:
5.3 Related PRs
5.3.1 Group by functions #1421 - not merged
5.3.2 Add hooks to let other plugins extend the Tasks plugin. #1249 - not merged
6 Backwards Compatibility and other concerns
6.1 Some personal wishes
6.2 Some ideas
At the moment, all the sample code above calls methods on the plugin directly.
6.2.1 Versioned API
I was thinking instead it might be good to design for future updates, so something like:
The idea here is that we publish an
apiV1
interface - which would use no Obsidian graphical classes, and so would be very amenable to TDD and automated testing.6.2.2 No writing of files in the first release
There is a very rare bug that Tasks can toggle the wrong line in a file. It is likely that the Tasks code for parsing and writing Markdown code may be replaced by datacore code, which is more performant and (I believe) better tested.
Until that happens, I would prefer the initial release of a Tasks API to support read-only access to user vaults.
Beta Was this translation helpful? Give feedback.
All reactions