Clojurians Log v2

> • LiveReload Live Programming lifecycle: Lifecycle of a “window”, how to [start, close, restart, refresh] This is a really good topic to add! > • Best practices w regard to styling. I'm not sure I've totally figured out this piece yet, but something is probably better than nothing > • Direct manipulation patterns I'm not totally sure what you mean by this

I refer to direct manipulation as when you surface part of app state with reactive UI controls (Ie control panel UI, or interact with component directly). Is this just a subset of reactive programming? But direct in the sense that through a ui event (especially a touch event) the user “directly “controls app state, with realtime feedback. I think this is probably old and somewhat obvious idea, embodied in most games and apps. But perhaps Membrane makes this affordance more accessible on a bespoke fine-grained level? Like how are Membrane apps more “moldable” than an average UI framework? Components auto-instrumented with “editor” UI? I think your dataflow repl editor example was great showcase, combined with incremental views of functions/editors!

Honestly, I think just trying to write idiomatic clojure goes a long ways. Building on top of plain ol clojure data makes a huge difference. Most UI libraries don't even have the opportunity since they're almost exclusively built on top of some OO model (web DOM, UIKit, GTK, Swing, etc.) I think you a great point though. I should definitely include something about why avoiding the typical OO foundations makes a big difference.

👍 Yes, your perspective on this is valuable. Some of these things are so intuitive conceptually, yet such a reach when it comes to wrangling competing fameworks/runtimes, that the imagination is prematurely forclosed. Like the idea you highlighted before about being able to just get and use current component state values. Kind of outside the view of certain declarative straight-jackets (css).

For basic usage, making an alternate viewer for clerk wasn't too bad, https://github.com/phronmophobic/desk

Dude! That's awesome!

You could connect it with the dag editor to create a dataflow editor!

I think you would have to build the DAG engine in addition to the UI

There are several implementations of dataflow engines in Clojure already Plug and play

I listed what I thought the requirements would be in https://clojurians.slack.com/archives/CQT1NFF4L/p1657482280025899. It didn't seem like any of the current options fit, but it would be great if I just overlooked something.

What about propagators?

Is that a library?

https://github.com/tgk/propaganda

It doesn't seem like it has side effects in mind

In what sense?

If it's using STM to run the steps within a transaction, then you shouldn't have side effects in the step.

It seems like there's a second implementation

Iirc there's also an immutable implementation without stm, eg system>system

Ninjad

maybe, the last time I thought about propagators was about when this library was last updated

Propagators seem like a natural fit for dataflow

I seem to remember something about propagators running until the system becomes "stable"

Not for the immutable implementation 🙂

Also, what about pathom?

The immutable implementation has a step semantic you can run until fixed point. Like macro expansion

pathom might help

or any graph library really

does pathom help you run your resolvers?

and can you inpsect the results as it's resolving?

I'm not a pathom expert 😅

me neither 🤷

propagators are nice because you can have cycles

But I THINK there's an implicit context which passes along with everything

Yeah I dont know if pathom has cycles

supporting cycles might be a requirement

The people demand propagators 🙂

Btw, dataflow + code editor = write code and visually see what values are doing throughout your code AS YOU ARE WRITING

We have a hackathon at work soon 🤔

my evil plan is spreadsheet for pure functions, data flow for impure functions, https://twitter.com/phronmophobic/status/1471612491645874176?s=20&t=CQ6vQtKoOS0eF4xWTDg1DA

I'm pretty happy with the spreadsheet (and use it regularly), but the data flow editor is still vaporware

Why spreadsheet and not something slightly more visual? (Like dag?)

I already nerd sniped you to write a graph editor 😄

that's a good question. I'm not sure they're mutually exclusive, but I think spreadsheets are very effective for pure functions and immutable values. generally speaking, the annoying thing about DAGs is density and tedium, especially if adding 2 numbers requires 3 nodes.

I think DAGs are much better at the flow aspect, where it's important to see where the data is coming and going. spreadsheet are nice for pure functions because each cell is kind of an island

and spreadsheets can be more visual, https://twitter.com/phronmophobic/status/1495102204520263680?s=20&t=_SZwU-5BoY0Q2nCvMx05jA

Isn't this just a specific visual representation of a graph?

Why not toggle between the two views?

yea, that could work

right now, I only have the one view

But you could have another 🙃

yea, that's goal

"I'm a stick" "But you could be fire"

The spreadsheet is closed source at the moment, right?

And wrt dataflow and representation, the spreadsheet currently won't be able to handle feedback loops, although pure

it's closed source, but not for any particular reason

if you were interested in trying it, I could try to make it usable

Usable? Where's the fun in that? I would connect it to desk and use the mechanism to represent data flowing through code as you edit it

I guess usable is the wrong word. I thought it depended on a bunch of local extensions to membrane, but I think all of those have since been released

I used the word "usable" when I really meant runnable on a second computer

oh, it depends on another unreleased project for the mini UI editor

This is an unrelated thought about code organization, but I wonder if such projects should be organized in monorepo where all the ancillary modules are under a modules directory

probably

I have a janky setup where I use :local/root and then change it when I commit and push to github. I think polylith solves this problem, but I haven't tried it

since the spreadsheet already breaks apart your code and it doesn't live in a traditional file format, I've also been investigating how to store code directly in the db rather than on the file system, but there are still problems to be solved there

https://clojurians.slack.com/archives/CJ322KHNX/p1665549828565529

haha

I've been playing with that but the tools analyzer output isn't ideal

someone else also posted about a similar topic as well, https://clojurians.slack.com/archives/C053AK3F9/p1665518469317489

It would be better if the keywords were qualified. And I'm not sure how to replace the entities with ids correctly

Codeq only does git, not the code itself

I might try throwing it into asami

of all the db options, I really liked asami

I don't think it supports range queries though, which can be important for some use cases

I don't have an opinion on the matter yet

I'm still pretty new to using them, but xtdb also seems good

> Pattern for doing Figwheel style n-up variations on data? I'm not that familiar with figwheel and googling didn't help. Is there a link or resource that explains this feature?

I would love to try the spreadsheet editor/repl out.

Managed to ingest the AST to datascript @smith.adriane

nice

Once you have the AST, you can turn it back into code you can eval, right?

yup

I’ve not had a chance yet to get into Datalog db’s, but have always been attracted by the idea of high-level graph query. Interesting how it might be utilized in the localized UI context.

dev cards is cool. Looks like there's a lot of overlap with something like clerk. I wonder how much work it would be to build an alternate viewer for clerk.

Yes, that’s what I meant, devcards! Interesting that Clerk also provides simultaneous visualizations of multiple related functions.

i don't think figwheel provides any help for that. Are you talking about devcards ? they work outside of figwheel but it was created by the same author. https://github.com/bhauman/devcards/

https://figwheel.org/docs/

I’ve not really used it. Looks like a batteries included Clojurescript Repl setup. But my understanding was that one feature it allowed was developing components with visual isolation, and simultaneously developing n permutations of a component side by side. ie designing for different screen proportions simultaneously.

there are some examples in the https://github.com/phronmophobic/clj-cef project, but it doesn't seem like people are that interested (although I think they should be)

That does look interesting