Fork me on GitHub
Vincent Cantin03:10:20

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]}]
   (for [my-map my-vector]
     (let [v (:my-key my-map)]
        (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.

Vincent Cantin07:10:42

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?

Vincent Cantin07:10:45

The overall “domino” cycle described in the documentation of re-frame is the same, the implementation will be quite different.

Vincent Cantin07:10:29

The event handlers will have the possibility to return diffs


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

Vincent Cantin07:10:39

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

Vincent Cantin07:10:34

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.


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

Vincent Cantin07:10:58

That’s the reason for Minimallist, Diffuse, VracQL, and Vrac.

Vincent Cantin07:10:30

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,

👍 3
Vincent Cantin07:10:22

First, I want it to work in the browser.

👍 3

anyways, I'm excited to see what you come up with!

Vincent Cantin07:10:03

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?

Vincent Cantin07:10:17

Reducing complexity for users and for me.

Vincent Cantin07:10:01

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