Closed olanod closed 3 years ago
Thinking out loud ... we could introduce a new method to the RequestHandler
(is it still a good name?) trait that constructs and returns the handler(init
, new
, etc.)(does this break the trait object constraint?), it could have a default implementation, maybe also add the Default
trait bound? Open to better suggestions!
Now thinking, allowing users to use environment variables directly as a way to configure their plugins should be just fine, still some things to consider
std::env
Deno.env
module that could be mocked in the browser or we can create our own namespace e.g. globalThis.valorEnv
.env
map foo
if there is an env var named FOO_BAR
the plugin should be able to read a variable BAR
.
Currently a plugin is only a function that handles a request. Plugins should be allowed to hold some state that is initialized at registration time.