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

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: (https://github.com/roam-unofficial/roam-toolkit/issues/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]

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]

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