The Plugin Registry Pattern

Show and tell
1

When building extensible things I want the extenders to be decoupled from the extender, as I do not know how many extensions will be built apriori and I want 3rd parties to be able to extend so its not possible to import all extensions upfront. So far I used to do this with a simple viewof inputs(new Set()) in the extendable which works pretty well. Extenders inject their plugin into the set and trigger a reactive update so now the extendee can reactively trigger a refresh using the new functionality. However, over time I also want to replace the extendee with a new implementation e.g. I have had exporter, exporter-2 and exporter-3 over time. Then it becomes bad that all the extendees have to reference the thing they are extending. Its the same kind of coupling the other way that only bites much later.

My solution is to decouple both sides via a centralized named plugin repository. Bonus is we can provide a nicer API than raw viewof wrangling. The plugin system manages all N x M plugin sets once and forall!

2

It’s a bit abstract to me but I’m glad you got a pattern working that you like!

I noticed that your notebook doesn’t work in New Observable; it‘s because in the new standard library, Generators.observe returns an async generator rather than a synchronous generator that yields promises (because async generators didn’t exist at the time the standard library was first released).

To fix it, you need to say (await gen.next()).value instead of (await gen.next().value).

3

Thanks, works on 2.0 as well now!

It was await (await X.next()).value) (double await) that worked across both.

yes the that level of abstraction would not be appropriate for most notebooks.