Self hosting bundles

[paulsonnentag]

This is a first step towards self-hosted patchwork

• data types and tools are lazily loaded only if they are needed
• data types and tools are exported as

https://www.loom.com/share/1bf46c7239d14ef88fc99784d71fb230

Todo

• allow to load data types / tools from external urls
• allow to load data types / lools from automerge documents

[netlify]

✅ Deploy Preview for tee-production ready!

Name	Link
🔨 Latest commit	3f1eecc
🔍 Latest deploy log	https://app.netlify.com/sites/tee-production/deploys/6666f3f5aea77800095b28a2
😎 Deploy Preview	https://deploy-preview-61--tee-production.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[paulsonnentag]

This needs a bit more work:

• Loading modules from external sources only works for tools, not datatypes. We could add a type field to the metadata so we can detect what type a module is.
• The current implementation doesn't handle the case where multiple tools / datatypes with the same id are loaded. One way to solve this is to add a prefix to the id based on the url that a datatype is loaded from.
• Another blocker is that, currently the import map-based approach for loading a shared version of automerge across all files doesn't work in the service worker (In this branch the service worker setup is currently commented out)

One way to scope cut here is to keep the lazy loading of the modules and remove the dynamic loading for now.

[geoffreylitt]

Very nice progress!

Loading modules from external sources only works for tools, not datatypes. We could add a type field to the metadata so we can detect what type a module is.

I wonder if we want to allow a single module to export both a datatype and a tool. (Or more generally, any number of datatypes / tools?) In practice it seems like a common pattern to define a tool and datatype together, so we should make sure that's not overly annoying to do...

The current implementation doesn't handle the case where multiple tools / datatypes with the same id are loaded. One way to solve this is to add a prefix to the id based on the url that a datatype is loaded from.

I saw the single centralized ID namespace as a crutch anyway -- what if we just use URLs as the unique identifiers, and then have separate human readable names?

Another blocker is that, currently the import map-based approach for loading a shared version of automerge across all files doesn't work in the service worker (In this branch the service worker setup is currently commented out)

Curious to hear more about what the limitations are here and how fixable we think they are...

One way to scope cut here is to keep the lazy loading of the modules and remove the dynamic loading for now.

Curious if lazy loading on its own would get us any tangible benefits? Maybe would be better to just keep pushing on dynamic loading if the end goal is loading from automerge docs?

BTW, this might be further down the road I'm curious if you've thought about how we'll eventually handle modules that are updated while they're being run -- I'd assume currently you'd need to do a page reload to get new module code?