@lee.justin.m I’m curious though, what happened to the original author of these things? I don’t know that I see a presence of them around the slack channel, and not sure on GitHub either.

@U0LK1552A I’m just as curious! Dan Holmsand or something like that appeared to have written everything and then he just dropped off the map as far as I can tell. It’s really interesting how these things happen.

I think I’ve asked Juho before if he knew anything but he didn’t.

ah a mystery

Yeah, I’ve seen that Dan appeared to do a bunch

It’s a really popular lib and I am often confused who runs the show

which is Juho I guess

When I did the documentation project I was really frustrated because it would have been awesome to have someone to just explain the thought process. He did SO MUCH WORK on the project including awesome documentation I’m a bit surprised that he’s totally checked out.

yeah, it is odd

he is like the Santoshi of cljs

I think Juho stepped in at some point. He’s kind of a wizard. I have wanted to start helping with maintenance but I think I would need someone to really help me figure out WTF some of this stuff is. I understand a lot of reagent now but I still run into things that just baffle me (like how the react component caching works)

hahaha

that’s funny

his twitter and github seem dormant too

well thanks for the info, I knew you did work on the docs etc and I was following along, but was confused why the main author has never chipped in before - and now I know it is a mystery

This is a little scary. I have been thinking about doing a blog series on various reactive hacks out there. And as we speak I am trying to conjure up an example that will test if ratoms are susceptible to glitches.

One of these days I’m going to try to go through the impl enough to doc some of it. I’ve followed through it before and generally can understand it. But yeah. Need a deep understanding to find edge cases.

Some of the trickiest parts is how different reactive objects hold links to each other. And how there are various caching mechanisms they use for apparent performance gains.

I am going to take a peek at the code now, I am curious what mechanism might be in use. Some libs use transactions, MobX uses mark-and-sweep. I am an outlier, I use an integer “pulse”.

Yeah you have some background in various techniques. May be good for gaining insights.

The good news is is the core of the codebase for reagent is pretty small.

Just has plenty of little details to try to follow. Hah

Damn, that code looks familiar. I always, say, the problem determines the solution.

I got excited when I saw ratomGeneration thinking it was my pulse but it seems to be just for dev/debug.

“apparent performance gains” Yes, depending on the application, caching can be indispensable to the paradigm performance-wise.

Yeah makes sense.

In effect, the caching is what makes what I like to call functional state feasible. When we stumbled onto dataflow we just wanted functional state, but we were doing complex GUI layout computations so performance forced us to track dependencies so we could propagate intelligently and minimize computation. We never meant to do dataflow, it just forced itself on us. 🙂

Would be good to have a simple example to check it out

Re-frame primarily (only?) uses reactions though I believe.

So if it is specific to ratom, may not be the same there.

Could be wrong too. Well I guess app state is in a ratom actually. Will have to look around

(def xx (r/atom 0))
(declare bb)
(def zz (r/track! #(let [r (if (> @xx 3)
                             (+ @xx @bb)
                             @xx)]
                     (prn :zz r)
                     r)))
(def aa (r/track! #(do (prn :aa)
                       (* 10 @xx))))
(def bb (r/track! #(do (prn :bb)
                       (* 10 @aa))))

Now increment xx until it gets to 4 and you will see zz take on first 304 and then 404.

Changing xx marks zz and aa as dirty, but does not mark bb as dirty. xx notifies zz first and it runs and gets a now obsolete copy of bb. xx then notifies aa who notifies bb who then re-notifies zz.

xx cannot be sure bb is dirty because aa might not change. MobX has two dirty states, definitely and possibly, which here would be applied to aa and bb.

Interesting. Will check this out soon.

The trick MobX and my hack both use is to make one last check when deref-ing that the value being grabbed is current.

btw, having the dependency on bb conditional is not (I think!) necessary to expose the glitch. It is there just to defeat naive solutions as “check all your dependencies before running”. Since zz does not yet know it will branch to a read of bb that will not surface the problem. That is why MobX and I check for currency as the actual read of any ratom is executing.