take a look at buddy and co

what is the and co?

It was quite a long time ago, but I got to the conclusion if want to have it good write it yourself

I didn’t find anything what satisfy me

But I don’t really remember details

Okay, thanks.

I haven't had that error w/ Docjure myself what does the stacktrace look like?

typically with clojure we don't install deps, we use a dependency manager which caches deps and calculates a classpath including the cached artifact

if you literally mean installing the dep (eg. via OS package manager) I have not successfully used debian installed java libraries with clojure, and it always ends up being easier to use the dep manager (eg. clj or lein) to add the dep

One of the interesting things I've seen with e2e tests is allowing the driver to inspect the client state directly to make assertions and drive the tests.

Pulling the client side state in our app is as easy as

(defn- get-state [driver]
  (read-string
   (api/js-execute driver "return window.getState()")))

We've been using https://github.com/igrishaev/etaoin at work and it seems to work pretty well.

interesting, thank you! Ill try it out.

It still won't save you form mutating data if you need to pause and resume processing on the very same data. But if you can change the reference to the data like you'd do with regular assoc, you can do what JS does, in pretty much the same way, no?

the reference identity isn't important but what I'm stuck on is trying to imagine what kind of structure would allow me to stop and resume it

I guess I have to keep track of where in the tree I'm currently working on

which is why it seems like a zipper

you can definitely do this with zipper.

It's not a tree, it's a graph, so just having reversed or two-way references won't work if the path is important. You need to record the path. A zipper is indeed fine. But if any branch within a node can be identified with a single unique key, then just a vector of such keys will work as well.

I'm going down the zipper route

you could also use any of the graph libraries like ubergraph/loom

not sure if your graph will have cycles, but if it does, it seems like using zippers would be cumbersome

I say graph but I'm p sure it's a tree, so zippers should be ok

they just confuse me 😅

So, why not just a vector path? Something like [:a :b :c] for a tree that's just {:a {:b {:c 1} :d 2} :e 3}?

I think that's basically what zippers do they just have more algebra already done for you

Not sure what's mean by algebra here. They don't have anything that's not simple up/down/left/right navigation with some mutation. If your tree doesn't have a concept of left and right siblings, then zippers won't be a good fit IMO. In the above toy tree, that's exactly the case. What's the path "down from :a"? There's no such thing. What's the path "to the left of :d"? Again - no such thing. But if your tree is more similar to a nested vector, then zippers might be more suitable. Although vectors are still associative, you can store a vector of indices as path.

> They don't have anything that's not simple up/down/left/right navigation with some mutation. zippers are immutable

FWIW, I did include some https://cljdoc.org/d/rewrite-clj/rewrite-clj/1.0.644-alpha/doc/user-guide#_a_brief_introduction_to_zippers in rewrite-clj user guide - if that helps your zipper journey at all.

> What's the path "down from `:a`"? There's no such thing. it's easy to define a zipper navigation that does exactly this

> zippers are immutable That's just poor wording on my end. I mean that there are things like assoc but for zippers.

I understand what you mean p-himik. In my case, my tree has left and right siblings. to show my hand, it's a React fiber tree - so fibers that represent elements on the page have quite a bit of metadata about them and have siblings, children, etc. I'm guessing if I go about trying to do the book keeping myself, I'm going to end up recreating zippers from scratch - which would probably help me understand them more, but I want to be lazy on my three day weekend 😛 so I'm going to try and grok zippers a bit better first.

If zippers don't work out, try some kind of lenses, you can often get something very zipper like but a little more customizable

zippers are working really well so far

https://github.com/lilactown/react-clj/blob/main/src/lilactown/react/fiber.clj 🙂

it looks like reconcile-node could probably be simplified to:

(zip/edit loc perform-work)

ah good tip. I've added more to it now, but I could probably move that into perform-work

general context

I tend to use the zipper operations as low level ops and use them to create higher levels ops that more directly fit my use case.

it's about building the tree itself. I have some config that would change how the tree is constructed, and I'd like it to be associated with the in-progress tree I'm constructing with a zipper

I guess for now I'll keep a bookmark:

{:config <config>
 :wip-tree <zipper>}

Can you put it in the metadata of the zipper when you iterate through the nodes?

Depends a lot on your algorithm of course, but I think I’ve dones something like that. My use case was modifying an existing tree, though.