Consider including roam-navigator

Hi! I’ve written a fairly extensive extension, augmenting Roam with keyboard driven navigation. When I mentioned to Conaws that I was thinking of writing a keyboard shortcuts extension, he recommended contributing to roam-toolkit.

I went ahead and started my own codebase because most of the code is copy-modified from my todoist-shortcuts extension. So I just needed to adapt it to Roam’s DOM which took me a fraction of the time it’d take me to implement the same thing within the conventions of roam-toolkit.

The two extensions can be used just fine simultaneously. However, I would still be keen to add roam-navigator directly to roam-toolkit. This would have quite a few beenefits:

• Fewer extensions for Roam users to install.

• We could get this functionality out to the folks already using roam-toolkit.

• Could use roam-toolkit’s existing configuration code for settings.

• I wouldn’t need to create an icon for roam-navigator.

I propose the following approach to this:

1. I’d open a PR adding roam-navigator.js + initial integration with roam-toolkit configuration.

2. Y’all would add direct commit access for me to roam-toolkit, with the understanding that I’d only do direct pushes to roam navigator code (and PRs for changes to other files in Roam Toolkit)

3. We’d plan to omit typescript annotations from the roam navigator code. I could be swayed to include them, but I really like having a workflow where I can modify the code and have that immediately be reflected in the extension (no build step). While I am a big fan of static types (esp powerful type systems like in Haskell), I actually don’t think this variety of code benefits a whole lot. Things pretty much work or not, manual testing can be pretty exhaustive as there isn’t a whole lot of relevant variety in the execution state space. Types certainly would help for documentation / collaboration, though.

4. Plan to not gate the PR on a big refactoring splitting it up or make the code more readable. I know, some parts are a mess, but for me it’s a familiar mess! There is just one big file. I think it’s more valuable to polish the outward behavior than the inner beauty of this variety of code.

What do you think? No problem at all if you’d rather keep the two separate, I actually wouldn’t mind that, because:

• I think the name “roam navigator” is rad. Astrolabes (roam logo) can be used in navigation.

• It’s fun to watch extension user count rise.

• I could have my own sponsor link to my buymeacoffee page.

For me what really counts is getting this functionality into people’s hands, though, so overall I am more keen on including it in roam-toolkit.

[mgsloan]

a separate domain that only you understand.

Yes separate domain, but not one that only I understand. The code is messy, but not unintelligible. It has some comments, and most things are straightforward. Right now my estimation of the expected benefits of rewriting it is far outweighed by the cost of doing so. This might change if it becomes popular / if potential collaborators express that the structure is a roadblock to enhancements. But that is quite uncertain, and so it is more efficient to hack something together.

upon reflection - I don’t think this will work under conditions you’ve described

Makes sense! I picked out an icon and have published it as an independent extension. Feel free to revisit this decision in the future if info changes.

But if we build it for the toolkit it should be done in synergy with existing work on vim mode and other parts of the extension.

I haven’t been able to build the vim branch successfully, but I don’t see any a-priori reason that the vim mode would conflict with this extension. Maybe a little weird to have two different link hinting systems.

I certainly look forward to the vim bindings, particularly the o and shift+o bindings. i will try to make the extension synergistic with that once the vim bindings are released. Part of the motivation of inclusion of roam-navigator would be such synergy, but it can probably be managed without sharing a repo.

fyi the npm run watch mode with autobuild/reload works really well

Good to know! My experiences in the past with npm have been uhh “varied”, to put it politely. Perhaps it’s from not putting in the time to learn how to use it properly / work around its failure modes. So far I only write javascript for browser extensions, most of my clientside work has been transpiled from Haskell.

[Stvad]

We’d plan to omit typescript annotations from the roam navigator code. I could be swayed to include them, but I really like having a workflow where I can modify the code and have that immediately be reflected in the extension

fyi the npm run watch mode with autobuild/reload works really well