refactor base modules
%XK3vMNie/hbhHfAN9V2EBn6DdR86hz9naFAVOlDxWes=.sha256
master
from base-modules
refactor base modules
at the moment the "base" components of patchbay
, especially the return values of ssb-config
and ssb-keys
, are not depject
modules.
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 config
and keys
, but also possibly including feed
(the return value of ssb-feed
) and 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 depject
.
previous conversations:
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, 8:34:43 AMhey @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: keys
and self_id
. can this be resolved if we applied the modules in dependency order, rather than in order added? thanks. :smile:
@dinosaur there are some modules where there are cyclic dependencies. Simplest is to put the setup code that calls other modules within a nextTick
.
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