My first thought would be to return an id for reading the result in the future. Then you could customize your merge fn to recognize there are asynchronous results and start polling.

It's definitely possible, but I don't know of any examples.

Interesting, why do you think merging would be necessary? I thought no outside state needs to be involved, just the final tree of data composed by a recursive parser.

You gave me an idea though, what if :read fn returns {:value async-channel-with-val}, and then I just wrap parser function to loop through map values, see if they are channels and wait for their resolution (and return channel itself). In theory that could work recursively too. Not very good with core.async yet, but I’ll try to put it together

The final tree of data will not be final in your case, it will contain placeholders for things that appear later

You'll need a way to trigger a re-read on components after the data is available, which is where merge comes in

@adambubenicek pathom has full async support if you need it, so I think can get a good head start there

Indeed, I was describing a different kind of async, if waiting isn't an option

I just don't recommend using pathom as your client parser (the one that runs in the reconciler, the base parser) because it probably will be slow for that, pathom is more focused on remote parsers (that can serve your 'sends' from local, or on the server, node.js or clojure)

Pathom does look very good. Frankly, I wanted to start with something smaller and simpler (om next appears to be), mainly to learn. But in the end I probably should use Pathom (+ Fulcro). Thanks!

@adambubenicek to be honest, I think Fulcro is simpler than Om.next, it can look scary on the outside because it seems like "more stuff", but it gets you ahead in a lot of things that require manual implementation in om.next, like the local parser