refactor base modules
at the moment the "base" components of
patchbay, especially the return values of
ssb-keys, are not
this leads to the following duplicate code in many modules:
var config = require('ssb-config/inject')(process.env.ssb_appname) config.keys = ssbKeys.loadOrCreateSync(path.join(config.path, 'secret'))
since many modules use properties from the config, with this pattern every module is stuck with the config it fetched itself.
as in, there's no way to dependency inject a modified config to an existing module. this leads to
patchwork-next duplicating modules when really you just want to change the default config overrides.
i'm interested in pursuing an idea, whereby we make a set of "base" modules, starting with
keys, but also possibly including
feed (the return value of
connection (the return value of
pull-reconnect as it applies to the ssb connection).
the goal is to further modularize, so we can reduce duplicate code, given the power of
oh, and this pull request is a work in progress, do not merge yet please. also will be better to wait after %OSDN2p2..., since that improves
depject in a way that helps here.
great. I am in favor of this!
cde57d98· 12/18/2016, 3:34:43 AM
hey @dominic, so i'm trying this again but have hit a snag: if a module needs to use the config during create (for example, see
modules_core/blob-url.js) then it errors with
depject.first: plugins not loaded yet. i think the same would apply to the other base modules i made so far:
self_id. can this be resolved if we applied the modules in dependency order, rather than in order added? thanks.
@dinosaur there are some modules where there are cyclic dependencies. Simplest is to put the setup code that calls other modules within a
We could load modules in dependency order if cyclic dependencies where detected and handled specially. Then the advice about
nextTick would only apply for modules with cyclic needs.
Built with git-ssb-web