Clojurians Log v2
vrac
Hi @smith.adriane. You can read this room’s historical content at https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/vrac
Today, I am going to work on VracQL a little bit.
yea, i’ll definitely check it out
I've been experimenting with alternative ui paradigms and vrac seems really interesting in part because it seems very similar to the approach that I've been pursuing.
basically, it's the same idea of tracing the usage of component/template properties via macros. I was curious to see how reactivity was handled to see if that was also similar. the way I've been handling reactivity is to have have the macro (`defui` in my case), translate any symbol with a "$" prefix to the keypath of that variable. I've been using specter for updating via keypath, but it seems like pathom would also work similarly.
as a an example:
(defui my-component [ & {:keys [my-vector]}]
(apply
ui/vertical-layout
(for [my-map my-vector]
(let [v (:my-key my-map)]
(ui/on
:mouse-down
(fn [[mx my]]
[[:do-something $v mx]])
(ui/label v))))))my-component would be a component that is a vertical stack of labels of the :my-key values of the maps in my-vector. when a label is clicked, it would dispatch an :do-something effect with the keypath of v with the x position of the mouse as an argument. $v is translated by the macro to the value [<path-to my-vector> (nth <index>) (keypath :my-key)] .
not sure if that description makes any sense.You might be interested my this tweet serie: https://twitter.com/VincentCantin/status/1321705697092857856
I also have plans to pass the locations of parameters in the events.
yea, seems pretty similar (to me).
is a reducer in vrac the same as an effect handler in re-frame?
The overall “domino” cycle described in the documentation of re-frame is the same, the implementation will be quite different.
The event handlers will have the possibility to return diffs https://github.com/green-coder/diffuse
my goal with separating what from how is to not enforce any specific implementation. obviously, having a reasonable default is important, but if you have data model, you can allow the application developer to choose the implementation that's best suited
Things will be clearer once I reach the milestone.
:thumbsup: . well, I'll follow along in the channel. thanks for withstanding my barrage of questions
I am designing Vrac as a framework where the user has all the systems in small pieces. They are made to be assembled together or to be replaced individually.
That’s the reason for Minimallist, Diffuse, VracQL, and Vrac.
haha. from my docs: > While these three layers are made to work together, they can also be mixed and matched with other implementations. seems like we're maybe walking down similar paths
Still, getting to something that works is my first priority, so what people will get at the next milestone might not be what they want.
if you're ever interested in having vrac work on desktop or in terminal, you may be interested in the graphics layer of membrane, https://github.com/phronmophobic/membrane
First, I want it to work in the browser.
anyways, I'm excited to see what you come up with!
For the next milestone, my target is to have a realtime application which runs mostly server side.
interesting. what's the reasoning for having it run mostly on the server rather than mostly on the client?
Reducing complexity for users and for me.
I want to have something that works, and this seems to be the most convenient “debut” for both the user and myself.
I've always just assumed that splitting the logic requires adding a network layer which makes things more complicated, but I guess there are plenty of well known techniques for solving that issue