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

Discussion: drop configuration loading #63

Open
rijnhard opened this issue Feb 18, 2021 · 0 comments
Open

Discussion: drop configuration loading #63

rijnhard opened this issue Feb 18, 2021 · 0 comments

Comments

@rijnhard
Copy link
Contributor

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant