What is roam-toolkit's relationship with Roam's eventual API/plugin system?

[tntmarket]

The goal of this issue is to collect thoughts about what'll happen to roam-toolkit once Roam's API/plugin system is released.

roam-toolkit's current role

Value proposition

Currently, contributing to roam-toolkit rather than making your own extension is beneficial because:

Easier to build the tool

Infrastructure such as typing, modules, hot reloading, and reusable code make it easier to build more complex plugins, compared to hacking with vanilla js in a userscript.

Easier to reach audience

Tool makers can access the existing/future users of roam-toolkit, which also helps them get more feedback about their idea.

Don't have to deploy the tool

Tool makers don't have to set up and maintain their own extension in browser app stores.

Barriers to contribution

Tool makers may not contribute to roam-toolkit to avoid the overhead of integrating with the codebase, and going through the PR/contribution process. Example: (#91)

As roam-toolkit accumulates more features, supporting old features plus reviewing new features will be harder to keep up, unless roam-toolkit recruits more maintainers.

Relationship with Roam's API/plugin system?

I don't really know what the plan for Roam's plugin system is, but it'd be ideal if we could focus on complementary functionality.

I'm guessing they'll eventually have:

• APIs for reading/writing the database (doesn't conflict)
• A marketplace for distributing plugins (doesn't conflict)
• APIs for implementing user facing features (kinda conflicts)

Potential futures for roam-toolkit

SDK/Library

Some helpers, and testing/development infrastructure might still be useful after Roam's API/plugin system is released. roam-toolkit could become a library for tool makers to reuse, or a template that tool makers clone when developing their tool.

Deprecate the project, and salvage the features themselves

Maybe Roam will release an SDK/API that obsoletes roam-toolkit's core functionality. In that case, we'd probably just migrate the features to Roam's plugin instead, and celebrate the value roam-toolkit gave up until that point.

In either case, it'd be ideal if the roam-toolkit -> roam-toolkit setting interface was close to Roam's eventual plugin interface.

Other thoughts

If we see roam-toolkit as a temporary solution for the lack of Roam plugin system + SDK, then we can probably afford to be less picky when accepting contributions, as long it doesn't touch reusable helpers and break other features. It's role would be to just help people prototype plugin ideas, until the real plugin system arrives.

If we see roam-toolkit as having a role, then it makes sense to prioritize more of the infrastructure/meta features, and keep PRs high quality.

[TDHTTTT]

Is it possible now to implement maybe some of roam-toolkit's function in roam/js right now? Anyone doing it?

[Stvad]

@TDHTTTT roam/js is not a future plugin system described in this doc, it's just a way to run userscripts. It does not provide any superior interfaces/etc vs running the extension. In fact the dev and runtime environment are inferior.
So theoretically it's possible to run toolkit over roam/js, but I'm not sure I a point..
Only advantage I'm aware of is portability (i.e. running on browsers other then Chrome* and Firefox)

[TDHTTTT]

Only advantage I'm aware of is portability (i.e. running on browsers other then Chrome* and Firefox)

Yes I was mainly thinking about mobile support

[tntmarket]

Maybe a blob of pastable [[roam/js]] code could be a webpack compile target, for people who can't/won't install a browser extension

[Stvad]

I tried that actually. I failed at pasting it in 😅 - it causes code block to stop render properly and so roam does not even try to execute it. Also it's a few hundred KB of text and roam takes it poorly when you try to paste that into single block =\

[TDHTTTT]

I tried that actually. I failed at pasting it in sweat_smile - it causes code block to stop render properly and so roam does not even try to execute it. Also it's a few hundred KB of text and roam takes it poorly when you try to paste that into single block =\

@Stvad 😄
Maybe instead of directly pasting, importing from outside like @roamhacker did in roam42
could help?

var s = document.createElement('script')
  s.type = "text/javascript"
  s.src =  "https://roam42.glitch.me/main.js"
  s.async = true

[Stvad]

huh, that can work actually! there are definetely more hurdles to overcome (like https://twitter.com/ViktorTabori/status/1284270036320948227 or usage of browser extension API) but this can be a step forward!

[Stvad]

tried that

Uncaught Error: This script should only be loaded in a browser extension.
  | r | @ | entry.js:formatted:10014
-- | -- | -- | --
  | (anonymous) | @ | entry.js:formatted:10019
  | n | @ | entry.js:formatted:11
  | (anonymous) | @ | entry.js:formatted:1160
  | n | @ | entry.js:formatted:11
  | (anonymous) | @ | entry.js:formatted:6412
  | n | @ | entry.js:formatted:11
  | (anonymous) | @ | entry.js:formatted:6645
  | n | @ | entry.js:formatted:11
  | (anonymous) | @ | entry.js:formatted:24665
  | n | @ | entry.js:formatted:11
  | (anonymous) | @ | entry.js:formatted:71
  | (anonymous) | @ | entry.js:formatted:72
 

is the error I get. which is fair, would need to dig deeper to decouple things from the browser API

[TDHTTTT]

@Stvad If you have time, please checkout the latest update @roamhacker had for roam42. The deep nav and jump nav are super enjoyable to use both on desktop and on mobile!

[Stvad]

it seems to be based on https://github.com/mgsloan/roam-navigator, which I'm aware of :) I achieve similar functionality with Surfingkeys and the Vim mode of the toolkit

[Stvad]

created #164 for discussing running over roam/js.

[Stvad]

fyi uploaded poc for running on roam/js in #164