Questions around configurable defaults #14
Description
The tension between general purpose (code re-use) and Caltech Library specific (e.g. SFL hours of operation) suggests an opportunity for leveraging configuration. What should be in that configuration should be explored.
Use case: footer-standard footer-homepage elements
A common feature in many websites is an informational footer. Often the text benefits from standardization. By implementing a custom footer element you could bring a design system approach into your HTML markup. This may work well in many situation (e.g. SAAS customizations, static site deployments). It is unclear what should be fixed versus configurable to make the custom footer elements be as flexible and useful as possible.
Customizations of a Web Component can be implemented as attributes and as innerHTML content. Another approach would be through injecting default values in the bundling processes used to assemble the distributed version on CL-web-components.
In this case you'd use a configuration file, defaults.yaml, that was used to generate a module holding default text and settings, defaults.js. These files could then be pulled into your web component via an ES6 import statement. The bundling process (esbuild.js), deno bundle, would then resolve the imports into standalone the web component JavaScript file.
In the specific case of a standardized footer or header this would allow the specific institution or organization to use the CL-web-component while adopting to their needs and branding.
Does it make sense having Deno as a require for regenerating the CL-web-component library? If so should that YAML file be checked into this repository or just have an example one included?