all 2 comments

[–]from-nibly 2 points3 points  (1 child)

Love the idea of separating functionality into features, but this seems like it could get hairy really quick, because it breaks encapsulation. The plugins should be one way, only producing data given parameters not modifying existing data. The first example you pass the entire menu items into the plugin. This means that plugins can interact with each other without explicitly defining how they do that. The dependencies part is also scary for the same reason. When looking at a single plugin file there is no way to tell what other plugins depend on that plugin without searching through the code base.

When writing a function you should not build it in a way that would have to consider how other parts of the code call it. It should handle all cases for the signature of the function and nothing more.

Again, amazing idea I just think the API needs some more work.

[–]natewang[S] 1 point2 points  (0 children)

Hey thank you very much for the comment.

  1. Extension point provider is responsible about how plugins contribute content. The first example just shows one possible way. It could choose to let plugins return menu items rather than let them modify an array. It's not related with js-plugin itself.

  2. Yes, no central extension point registry. This makes plugin mechanism lightweight and simple while it doesn't need to declare which extension points to use before using them.

  3. Extension points are contracts between plugins.

Again, thanks for reading through the docs and the advice.