TaskAPI Design

[knoxy5467]

Use cases

• Allow actors to retrieve the full task list through an API call
• Allow actors to retrieve the task list with some basic filtering (complete, overdue etc) through an API call
• Allow actors to create, edit, delete tasks through and API call without using a modal.
• Allow actors to subscribe with a callback to be ran when tasks are edited.

Requirements

• tasks should be assigned a persistant ID that will carry over from one session to another.
• the API calls should be public and return a string or JSON representation of the task \ tasks

How

I propose that in the indexFIle portion of Cache.ts we can change the logic to assign each task an ID these ID's would be stored in the frontmatter of the document in the order that they appear. This would allow for persistant Task ID. however we need to create logic to identify when a change moves a task from one line to another line or when the order changes.

this is a hard problem. We could also consider this as a relational database would. What are the parts of a task that make it unique? I would say that the dates are unique idenifiers, and probably the most important peices of information regarding a task. if a task does not have a due date then maybe it does not need to have a unique identifier?

We could also consider just having an inline ID field that is added to all tasks, this could just be the task number in hex or base64 which would mean that even if a user has many tasks the ID would stay small. If the ID field is clutter for an indavidual then we could add a toggle in the settings.

overall having an ID for each task is a problem I do not exactly know how to solve. can we detect when a task is changed or moved? or do we just reparse the entire file again?

[claremacrae]

Hi, thanks for the write-up.

Having thought about this after our conversation last Friday, it's an enormous topic, with a real risk of getting bogged down and never finishing.

So I would like to take it one step at a time, and you've listed them in a good order, from simple to complex.

So let's please start with this one first: Allow actors to retrieve the full task list through an API call.

It will be a good test case of what is involved in adding to the API - and it will require thorough tests, and clear documentation.

It's a self-contained body of work, that can be released to users, and should be a single PR, ready for release once done.

And once that's done, we can pick up the next item on the list, and talk about how that will work.

I can't remember if I pointed you to the following before - but here's my boilerplate text...

---

I wrote a Contributing Guide.

These links are probably the most relevant sections when getting started.

• Setting up your Tasks build environment
• Running the automated tests and writing new ones
  • Even if you are familiar with writing unit tests, and with Jest, you should definitely read Introduction to Approval Tests, and make sure you have one installed of the supported diff tools
• How to make common edits, like adding new a new field to task

[claremacrae]

Allow actors to retrieve the task list with some basic filtering (complete, overdue etc) through an API call

I believe that implementing the above would address #2459. There is sample code in that, of how I did in my fork of Tasks.

[claremacrae]

The label to search for, to find related Issues and Discussions is scope: for plugin developers.