-
Notifications
You must be signed in to change notification settings - Fork 37
Open
Description
This thread is about the discussion around the topic so it should stay open for a while.
The idea is that the library shouldn't actually be doing the configuration because it violates the primary concerns of comedy.
As most advanced use cases would just use their own config loading.
However, hot-loading is very useful.
So I see a number of options:
1. make hot-loading configurable: by providing a custom handler and an array of files to watch:
const CONFIG_FILES = ['file1.json', 'file2.yaml']
comedy.setConfigLoader(CONFIG_FILES, (changedfile) => {
// custom parsing and handling
// then return the updated config in the JSON format currently read directly from files
return {};
})
2. rip out hot-loader functionality and just provide a hot-update function, maybe making another library
import hotloader from `@comedy/hotloader`
hotloader.watch('file1.json', () => {
// callback fires on config changes
// custom parsing and handling
const config = {};
// then return the updated config as a JSON object in the format currently read directly from files
comedy.updateConfig(config);
}
hotloader.watch('file2.yaml', () => {
// callback fires on config changes
// custom parsing and handling
const config = {};
// then call update with updated config as a JSON object in the format currently read directly from files
comedy.updateConfig(config);
}
there are likely other options, the biggest issue is backwards compatibility,
I lean towards option 2 because it keeps comedy focussed on what it should, which is the actor system, and you can
keep BC if you detect that the @comedy/hotloader module is installed and the config option is set as a path to a json file and not a json object (which it should support as well)
Metadata
Metadata
Assignees
Labels
No labels