Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plugins #977

Open
dave-doty opened this issue Sep 2, 2024 · 1 comment
Open

plugins #977

dave-doty opened this issue Sep 2, 2024 · 1 comment
Labels
challenging indicates that fixing this issue is expected to be more challenging than average enhancement New feature or request

Comments

@dave-doty
Copy link
Member

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.

@dave-doty dave-doty added enhancement New feature or request challenging indicates that fixing this issue is expected to be more challenging than average labels Sep 2, 2024
@dave-doty
Copy link
Member Author

dave-doty commented Sep 2, 2024

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
challenging indicates that fixing this issue is expected to be more challenging than average enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant