SNAPSHOT for 3.6 updated again (or use sha 3ad99ee6b961afb0d8a549f2ed798f4e8abfed6d) • Officially adds batched support (if you enable it) • Sync tx processing can now also use the batched support (if enabled) • Fixed abort IDs on sync tx processing NOTE: sync tx processing does not support pessimistic transactions, but if you are not using those, then I think the new sync tx processing is a great choice for most apps. It can break things on existing code because it can change behaviors slightly, but probably won’t, and with batching enabled it will: • Reduce network requests • Reduce full-stack latency It also occurred to me that I should be recommending that people leverage the abort system more, esp on routing. Here’s the pattern (will document soon): • Write a wrapper for load called rload (for route load) that gives ALL of the loads the same abort ID (e.g. :route-load). Use that for loads that are route-specific, and use df/load! for loads that have to complete no matter what. • Write a wrapper for your route changes that first calls abort on the route-specific abort ID, then changes route. That will cancel all of the loads that were for the route that the person just left. You might need to get more fancy with that, like have the abort ID be a parameter so it can tell that you are actually changing routes in a way that should cause a cancel…but because loads are queued rapid user switching can cause big delays while those (no longer needed) loads continue blocking the queue.

See the README on the react18 branch if you want to use React 18 with it, but it should work with 17 as well. React context is required, so older versions than that are no longer supported. @kevin842 this version should fix the react keys problem.

Update Dev Guide as well: https://book.fulcrologic.com/#ReactCompatibility

I see a weird behavior with RAD picker options. The BE query returns {:all-tags nil} yet somehow I end up in the client DB with ::po/options-cache {:all-tags {:options [:tag/id nil], :query-result [:tag/id nil]}} . My bad, my resolver forgot to wrap the query result in {:all-tags ... }

On further reflection, the synchronous transaction processing, especially with a production build, is probably going to run the loads as they're submitted so quickly that it won't have a chance to batch anything. So, I guess if you're going for the minimum number of round trips then using the batching transaction processing does make more sense than the synchronous. The only time the synchronous processing will ever batch anything is if there's already a transaction running when things are submitted, since it has to wait on the first thing in the queue to finish before it can do the next thing.