Feature: Add method to plugin object to expose day plan

[joshuacoles]

I have been wanting to work with my day plan outside obsidian so I forked the project to expose this data on the plugin instance. This involved the following,

1. Adding a getTasks(visibleDays: Moment[]): Record<string, TasksForDay> to the plugin object
2. Refactoring out the behaviour of the Svelte store hooks used to compute the data into standalone functions that can called from a non-svelte context.

Is there something that would be appreciated upstream and if so is there anything I should change before opening a PR? I do not have much experience with Svelte, so the changes around the hooks may not be needed for this use case.

My fork can be found here and I am happy to answer any questions!

[ivan-lednev]

Hey, @joshuacoles, that's an interesting idea 🤔

For starters, can you describe what kind of scripting you do?

The biggest hurdle right now is that I'll need to clean up the Task interface, because it's a bit messy.

[joshuacoles]

Hey @ivan-lednev, I am using the method to expose the data to external applications from. This allows me to avoid reimplementing the parsing behaviour and keep a consistent view of the data between obsidian and anything external.

Currently my workflow is day planning in obsidian and then using an iOS app I have created to view my plan and start Toggl timers associated with each task, as well as soon show a live activity to keep me on track.

If you don't want to expose the full Task interface, a simple selection of the properties representing things that are less likely to change could be an option, or simply documenting that the return structure is internal and will change as the plugin evolves. For reference I am currently using the startTime, durationMinutes, and firstLineText in my app.