UI modules found on the web often feature polyfill or kick-start functionality out of the box.
“Add script tag, put class on element, auto loads!”
“Set boolean to automatically polyfill feature!”
This is wonderful, it makes these scripts very easy to use. But at the same time it makes them less portable. What if I want to manually use the exposed functionality? I don’t want the script to eat CPU cycles by querying the DOM for non existing classNames. “Just remove the auto load!” you might say, but modifying the script prevents me from updating to a newer version without having to modify it again. When you think about it, is it really a Datepickers’ responsibility to load its own instances?
Let me handle instantiation.
You can still expose this functionality. Just, when you do, don’t do it in your core module. Create separate files for each load type. Still easy to use, saves CPU cycles on load and results in a smaller file size for developers not using the kick-start or polyfill.
Expose Datepicker functionality.
The kick-start references the DatePicker and automatically loads it on DOMContentLoaded.
The polyfill version is almost the same as the kick-start but does some additional feature testing to see if the native date input type is supported.
For an actual module the UMD pattern is probably a better way to go. You could refactor the kick-start logic and reuse it in the polyfill setup. On top of this the kick-start could expose a manager object which exposes an API to handle automatically loaded modules. All functionality unrelated to the actual module but useful none the less.
With these adaptations in place, we’ve achieved a better separation of concerns. I’m now free to use your module without the kick-start logic or embed the whole system if I just want to be up and running quickly.