There's no discussion here about what modules should actually look like.
Module expectations:
Should have a specific purpose.
Should be maximally discoverable.
Should either be useable elsewhere or beagle specific.
Should be well documented, ideally with both inline comments and external dev docs.
Should be testable.
Currently, we've been using the prefix beagle- when defining beagle modules. I think this is suboptimal- it's not immediately clear what it is to someone who is unfamiliar with Beagle, although it does make searching easier for beagle developers. I think a better way to do this is to use keywords: tag every module that is meant to fit into beagle with the keyword beagle, and use this as the search delimiter. This would allow for modules to be used elsewhere, which is one of the goals above. For beagle specific modules, the beagle- naming scheme should apply.
Beagle Modules export:
Functional methods
CSS and HTML assets
JSON
An object may not export methods if it is just a one-off module, and they may not export JSON if they also export CSS and HTML. The CSS and HTMl assets may differ based on whether they are meant to be plugged into the extension or elsewhere (in the future). So - do we enforce that beagle modules always export CSS and HTML which can be plugged in directly to the Beagle sidebar, or do we build the HTML and CSS (and, ultimely, react partials) assets on the extension side? Alternatively, we could build a wrapper for each module that takes JSON and spits out partials. This may be a suitable way to enforce modularity best principles. For instance, a 'DOI' module might spit out JSON, and the module 'beagle-wrapper' would have a method doi which would take the DOI JSON and export static assets for the extension. This allows 'DOI' to be maximally resuable without needing to keep Beagle-specific code within it.
Finally, It is currently not set in stone how we require or install beagle modules. At the moment, in 'beagle', they are all listed in the package.json file, and then required in main.js. I think a better way to do this would be to have a separate field in package.json, called beagle, where we would list each beagle module that is going to be used in the extension. We could then use a life-cycle script to install each of those packages in a separate folder, beagle_modules, and require all modules in that folder in main.js. NPM suggests doing this, for now, while they work on implementing ecosystems over the next year or two.
Thoughts? I may of course have missed something obvious.
There's no discussion here about what modules should actually look like.
Module expectations:
Currently, we've been using the prefix
beagle-when defining beagle modules. I think this is suboptimal- it's not immediately clear what it is to someone who is unfamiliar with Beagle, although it does make searching easier for beagle developers. I think a better way to do this is to use keywords: tag every module that is meant to fit into beagle with the keywordbeagle, and use this as the search delimiter. This would allow for modules to be used elsewhere, which is one of the goals above. For beagle specific modules, thebeagle-naming scheme should apply.Beagle Modules export:
An object may not export methods if it is just a one-off module, and they may not export JSON if they also export CSS and HTML. The CSS and HTMl assets may differ based on whether they are meant to be plugged into the extension or elsewhere (in the future). So - do we enforce that beagle modules always export CSS and HTML which can be plugged in directly to the Beagle sidebar, or do we build the HTML and CSS (and, ultimely, react partials) assets on the extension side? Alternatively, we could build a wrapper for each module that takes JSON and spits out partials. This may be a suitable way to enforce modularity best principles. For instance, a 'DOI' module might spit out JSON, and the module 'beagle-wrapper' would have a method
doiwhich would take the DOI JSON and export static assets for the extension. This allows 'DOI' to be maximally resuable without needing to keep Beagle-specific code within it.Finally, It is currently not set in stone how we require or install beagle modules. At the moment, in 'beagle', they are all listed in the package.json file, and then required in main.js. I think a better way to do this would be to have a separate field in package.json, called
beagle, where we would list each beagle module that is going to be used in the extension. We could then use a life-cycle script to install each of those packages in a separate folder,beagle_modules, and require all modules in that folder in main.js. NPM suggests doing this, for now, while they work on implementing ecosystems over the next year or two.Thoughts? I may of course have missed something obvious.