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.
this has been superceded by the v7
Built with git-ssb-web