dave-doty
commented
2 months ago One idea for the architecture of plugins is that, since we have a very regular structure using React/Redux actions, middleware, reducers, and view components, the plugin could specify some number of these.
For actions, middleware, and reducers, this is hopefully straightforward (though I haven't thought through the details yet). We already have a list of middleware and another "list" of actions (not literally a Dart list but all the actions are defined in actions/actions.dart; the plugin's actions could be added to these); the plugin could just supply more of these. With the reducers, it's a bit more complex since they have a hierarchical structure, but it should be possible for someone to write a "top-level" reducer that is simply called in conjunction with scadnano's existing top-level reducer (before it? after it? need to think about this more). The plugin would have to "drill down" to the appropriate part of the state tree, but this should be straightforward since they would be hardcoding the reducer for one particular action or a small set of actions. Much of the complication of our existing reducer structure is that it has to handle all of our actions, but a plugin would not be handling many so would hopefully be straightforward.
The view is more challenging. I'm not sure how to let someone specify, for instance, that they would like something new to be rendered with every strand, for instance. The view is a large and complex tree, and I don't know how the plugin would say which part of the view tree their new component should go, nor how they could specify which props need to be drilled down through the tree to get to their component.
So it's hopefully straightforward to allow plugins that either modify the design, or allow some other effect such as exporting to a new file format, and to have a new menu item "Plugins", where the plugin actions can be dispatched by clicking on the appropriate new menu item supplied by the plugin via a list of menu item text labels. But currently I have no idea how a plugin would render new view components.
For example if we didn't have oxview export, one could implement it via a plugin whose sole menu item would be "Oxview export" that triggers the same action currently dispatched when you click Export-->oxView, along with specifying that action and the middleware that does the export.
But for instance, if scadnano did not support modifications, how would we add the new view code to display modifications? Really not sure. (For that matter, not sure how to add the extra context menu items to create/edit/delete modifications.)
Allow third parties to extend the features of the scadnano web interface with a plugin architecture.
Currently I have little idea how to structure this. We can brainstorm ideas in the comments here.