-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bringing ideas from farm #324
Comments
cc @pfrazee seems similar to what you're doing with "view files" in Beaker. |
This is also very similar to what Wireline are trying to do, I think. |
Another thing that keeps spinning in my head is when I think about What if we generalized As of existing widgets they could be thought as |
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). |
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)
wherelens
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:
Grow CodeContent component #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 onlyhyperfile:/...
one could be but maybe that could be addressed or in worst case component could create newhyperfile:/
URLs after changes.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 WIP - Inspector component #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
The text was updated successfully, but these errors were encountered: