Is there any video of the April 7 Untangled talk for Clojure PDX?

@maackle: https://www.youtube.com/watch?v=IeIyQDg9gBc

Thanks. I'm really sorry I was out of town and had to miss that one.

@wilkerlucio: Just curious, why not use links?

@tony.kay: sorry, I don't understand what you mean by how links could fix the :shared issue, I usually use shared for some external resources, on my application I use an shared atom to control when a transaction will flow to the remote (it's a bit a special case, but I need to retain information between an action call and a remote call of the same transaction, using a shared data was the easiest way that I found to accomplish that, it's better than a global since this can be instantiated by reconciler)

@wilkerlucio: Do you realize that Untangled serializes your transactions? E.g. We only send one at a time…there won’t be multiple of them in flight, and you can get a trigger that one has failed throuhg tx/fallback and that it succeeded with post-mutation…

But in principle I have no problem with exposing :shared…just making sure you’re not missing something

The trigger for your transaction still has to be caused by something (an event, timeout, etc), so not sure why the global app state isn’t a good place to put this information.

If it is at the top, then a link query can get to it from anywhere: [{[:ready? ‘_]}]

“retaining information” could mean you want something that wasn’t sent in the client transaction (but you decided in your action) to appear in the server mutation. How about this: If the calculation of that value is pure, then calculate it outside of action (don’t put it in app state at all) and change the remote mutation’s parameters, then use the calculated value (by closing over it) to do the action part.

…calculate value...
{ :remote (update ast :params assoc :v value)
 :action (fn [] (swap! state ….value…) }

embedding an extra atom (state) is a bit antithetical to the entire platform/language. You’re free to do it, of course. The calculation, in the context of a single transaction, is ensured that the app state won’t change between transact local/remote processing…so I think this approach should work for the cases I can imagine…the JS thread is completely consumed during the transaction…so nothing else can happen, can it?