mattly: there's no way, afaik, to go back up the tree from a sub-cursor. ref-cursors were partly introduced to fix the problem you're describing...but I have been reassured by people that ref-cursors should be avoided and perhaps a different approach is what's actually required

I got pretty confused the other day, since I couldn’t marshall a nested data structure with Transit. If I printed it out in the repl, it looked sane enough, but Transit didn’t like it.

The reason was that there was an Om Map Cursor nested inside somewhere.

How should I deal with such a thing? It confuses me that I do not need to deref the nested map cursor in order to print it in the Repl, but I do need to do special handling in order to marshal it with Transit. How come?

@grav yeah that would be an issue. But fortunately not a very challenging one. Add a handler for MapCursor and IndexedCursor.

you probably don’t even need to do that

just map MapCursor -> MapHandler and IndexedCursor -> VectorHandler

@dnolen: With that solution, the issue isn’t particularly challenging, you’re right there 😉

Anyway, it was more a question of my confusion about the different behaviour of writing something to the repl versus writing it to an http request.

But thanks for the pointer

@grav it’s because cursors are printable

being printable doesn’t make them magically transit encodeable

ah, ok. would some kind of indication that they are cursors be a good feature? like you have with regular atoms? that would probably have cleared things up for me earlier

ie

cljs.user=> (atom {})
#object [cljs.core.Atom {:val {}}]
cljs.user=> (om.core/root-cursor (atom {}))
{}

a root cursor is just printed as if it is a regular map.

@grav not going to do that

needless breaking change, and in general not spending any more time on cursor stuff

alright.

@grav to clarify, some people may be using pr-str and EDN transport

not going to break that just because somebody wants Transit

or is confused by REPL behavior

right, point taken!