v2: part 1: rearchitecting

[phildenhoff]

Why rewrite the existing Logseq Raindrop app?

Well, as much as possible, I'd like to avoid rewriting the app. However, there are some painpoints I'd like to address:

• Testing changes is quite difficult when we have to interact with both Raindrop and Logseq.
• If the Raindrop API is having issues, that prevents development (not been an issue... yet)
• If my local Logseq app's graph is funky, that prevents development
• Worst of all, though, is having to open Logseq, load the plugin, load some data, see if it imports correctly, etc. etc. It's an annoying process.
• Ensuring that old things don't break requires manually testing everything. There's no way to ensure that we're not causing regressions.
• The code is just overall very messy. I don't enjoy that. I haven't gotten better at writing Svelte, but I have written everything once. The second attempt is usually an improvement.

At the same time, there have been only a few contributions to the codebase. So I'm not really worried about breaking someone's mental model of how it works.

What is the plan?

• Change how the plugin loads so that the Logseq SDK is optionally loaded, using dependency injection.
  • I'd like to put some distance in between the business logic and Logseq.
  • This allows us to create a mock Logseq service that we can use for testing.
• Write a mock interface for the Logseq SDK that we can use for testing.
  • Must output JSON or similar so that we can test the plugin's output.
  • Ideally, this would allow us to make a new instance for — say — Roam or Obsidian. But I'm not focused on that... for now.
• Rewrite the app behaviour to use the new dependency injection pattern.
  • At the same time, I'll reorganize the code.
• Write tests

Then, we're moving onto the single-page approach (as opposed to the current page-per-URL approach).

[phildenhoff]

This work is complete with #46 merged. Not much of a v2!! We're gonna need to rename this to v2: part 1: rearchitecting