git ssb

16+

Dominic / patchbay



refactor base modules

%XK3vMNie/hbhHfAN9V2EBn6DdR86hz9naFAVOlDxWes=.sha256
Closed dinoworm ๐Ÿ› wants to merge commits into master from base-modules
dinoworm ๐Ÿ› · 12/5/2016, 6:42:00 AM

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:

%8Hn3tfJdtIO4wc+QlMeTtt1uhB6ZThwVkIfOckBq0p4=.sha256 dinoworm ๐Ÿ› · 12/5/2016, 6:47:23 AM

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.

%3QNdSww+jEnID4OZeLKE4eV88ZxaNyc8zdagPPpnFM8=.sha256 Dominic · 12/5/2016, 6:28:10 PM

great. I am in favor of this!

dinoworm ๐Ÿ› updated the branch to cde57d98 · 12/18/2016, 8:34:43 AM
%l624HcoDHEnm5Exj18SiibTiE2T3fx/om8EEbD48X3c=.sha256 dinoworm ๐Ÿ› · 12/18/2016, 8:44:12 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: keys and self_id. can this be resolved if we applied the modules in dependency order, rather than in order added? thanks. :smile:

%AQGFTCjO1IF3XAuo3HOIX4MVLNNsnHmH8l762V2eUfk=.sha256 Dominic · 12/18/2016, 11:29:59 AM

@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.

%eNVjzV3a3B2gJHmWN0iBXzZPcQhmSc4940OK4MTyheE=.sha256 mixmix closed this pull request · 4/13/2017, 9:47:19 AM

this has been superceded by the v7

Built with git-ssb-web