Bringing ideas from farm

[Gozala]

Playing around with pushpin a bit #310 and #316 I've come to recognize that what I really would like to accomplish is more or less what I wanted with my dat://code.gozala.io/ experiment (which is not too different from https://observablehq.com/) that is a way to write bit of code that lets me take piece of data and create either one off widget or a reusable one. I suppose I have being using it somewhat along the lines of spreadsheets except with bespoke interface tailored to specific task.

In fact farm was exactly that, well much better actually, as I find board to be a much better surface for this kind of interactions than a notepad that you have to scroll up and down or spreadsheet for that matter.

So I have being wondering if we could resurrect what makes farm so compelling. From my conversation with @pvh I get a sense that while Elm is a really nice language it proved to be very limiting in practice 😢 (which I'm afraid echoes experiences I had with it in my attempts to use it for https://github.com/browserhtml/browserhtml or even in mentioned https://observablehq.com/). However I think more compelling element of farm was the idea that everything on the screen was represented using (doc, lens) where lens itself was piece of code also stored in some doc.

I would like to bring this back but omitting (at least initially) Elm compiler. It also just so happens that I've had being using https://github.com/mozilla/reflex/ library which is more or less Elm architecture in JS, which does not require any compilation steps (type checker would be nice though).

So putting all this together this is what I would like to try:

1. Grow #310 to become an "lens editing" component, which essentially allows one to write little bit of JS that could then be referred & loaded via URL. Unfortunately it seems that hypermerge:/ URLs can't be loaded only hyperfile:/... one could be but maybe that could be addressed or in worst case component could create new hyperfile:/ URLs after changes.

2. Create another "pipeline" component which embeds "lens authoring" component or rather selector for existing lens and a data "doc" selector to project one with the other. I would like pipeline to not be limited to just (data, lens) where lens project (HTML) view but to allow data to data projections so things could be chained into larger pipelines, but that might be a bit of a stretch right now). Default lens could be inspector (see #316) so that just document would render something and from there one could choose to use another one, or create one.

Note that with something like this I could easily recreate tool I use frequently https://hackmd.io/ where I'd be able to use "code editor" component for typing markdown and "pipeline" component to render it's preview side by side or whatever will make sense.

P.S: I am still thinking through this idea but I'd share for feedback & in attempt to document it

[RangerMauve]

cc @pfrazee seems similar to what you're doing with "view files" in Beaker.

[RangerMauve]

This is also very similar to what Wireline are trying to do, I think.

[Gozala]

Another thing that keeps spinning in my head is when I think about data -> view and data -> data it's somehow always the leap from first to the second. I recall in one of the discussions at http://offlinefirst.org/camp/ there was an idea of attaching links to the data blocks (doc in the context of pushpin) for "rendered views" and links to "source code" for rendering those views.

What if we generalized data -> view to data -> data where output just happens to be an html document (that in fact maybe be worth even persisting as such document). That way pushpin could just render documents that happen to be HTML directly and ones that are not as a data inspector.

As of existing widgets they could be thought as Note : data -> html, Thread: data -> html, etc...

[Gozala]

Main problem with persisting & restoring html is event listeners however that also happens to be the problem I've dealt with when trying to get all of application logic off the main thread and I think I've got some ideas how to address that.

To be specific to make it work off the main thread solution I've settled on was to use a decoder.flow library that is inspired by Elm's JSON Decoder library where decoders are declarative parser comibantors that can be serialized, loaded into main thread and used to extract / encode relevant info from the event and pass it back to the thread where program is running.

In this specific use case I'm thinking composed encoders could be saved in the same document as rendered html output and referred to in hash using it's address (it's content hash probably).