git ssb

common boilerplate for patchbay and patchwork-next

I'm very happy that patchwork-next is largely compromised of bits of patchbay. It shares an architecture, but is essentially a curation of modules. What would be really good, though, is to unify the stuff around the patch{work,bay} modules, the stuff that opens the windows, and starts the background process, etc.

One thing that puzzled me was implementing the main-window.js as a module.export and then executing that with https://github.com/mmckegg/patchwork-next/blob/master/lib/window.js#L14-L60

Although, I realize I actually wrote code which is somewhat similar in intent, where I also have a base html file, but then I pass arguments to it via the query string:

https://github.com/dominictarr/electro/blob/master/index.js

What do you think are the relative pros and cons of these approaches?

okay digging into this furthur, I see that I can actually remove most of that stuff in the executeJavascript string. It could just be require(path). I like how sbot also runs in a "window" just not shown - I was thinking of doing something like this!

This code comes mostly out of Ferment. I was experimenting with ways of avoiding multiple window.html files, as ferment has about 6 different windows, and they all need a connection to sbot.

I realise it could be simplified a bit. I do like the idea of window.js files that just export a root element though, and with this method, the root element can also be an observable. I think that comes out of Loop Drop.

Yeah, this stuff doesn't make nearly as much sense in patchwork-next/bay as it does in Ferment where the archietecture is very different.

@matt what about a window.js that just adds itself to the dom instead of being added? I don't really see whole windows being reused, so exporting a thing doesn't seem necessary.

Yeah, that sounds fair enough.

I like the ability to be able to pass arguments to new windows though. What about half way, where it still exports a function that receives args, but doesn't return anything? Or maybe the args could be set as a global on the new window?

None of this stuff is really needed right now, but I am planning to put a few things (like onboarding) in a different window.

But really, this is just a carry-over from Ferment, and I'm attached to it for no logical reason :laughing:

@dominic In regards to browserifying bulk require, this is a pretty nice solution: https://github.com/substack/bulkify

I experimented using it when I was trying to make a browser version of Loop Drop a while back.

I think we should avoid using multiple windows and go for things that also work well in browsers and mobile. I want to maximize code reuse!

I reckon set global on window - a window is a process, so that would be analogus to process.argv and process.env (or window.location.search)

what do you think about how patchbay is organized, compared to how you did ferment? pros and cons?

what do you think about how patchbay is organized, compared to how you did ferment? pros and cons?

I'll have to give it some more thought, but the clear advantage to the patchbay "depject" model is that it is trivial to extend/override/replace things.

But I think the tradeoff is it can be hard to get a clear overall understanding of how everything connects up and the flow of information. It also makes it harder to figure out what file defines a peice of functionallity, and what else will break due to modification.

Code reuse is great for avoiding continuously having to update the same thing in a bunch of different places, but IMO a lot of the time can be a lot more trouble than its worth.

Maybe a balance can be found between the two styles?

Sure, I think one thing is that reuse helps separate the really good ideas from the right now ideas. Don't try and force things to be modular, but do look for things that modularize well, that is the goal of the ikea architecture

Having seen you using observables extensively has made me think about it again, and they where very handy in https://github.com/flumedb/ so I'm gonna use some of those bits back into patchbay.

but one thing I'm wary of is just copying bits from patchbay, instead of depending on it - some of the things in there would be better as PRs to sbot and/or patchbay. but using the layered style that will be easier, also I have a new idea to rewrite depject that will make it suitable for scuttlebot also. Also, thinking: maybe there is a way to label elements to show what plugin they came from?

Also, thinking: maybe there is a way to label elements to show what plugin they came from?

:+1:

some of the things in there would be better as PRs to sbot and/or patchbay

Absolutely agree!