Fork me on GitHub
Chris Lester08:04:00

I'm looking through the Fulcro book (after going through the tutorial piece) as I love the idea of using EQL (and diving into Clojurescript) but it's not clear if the EQL queries can be filled on the client without a trip through to some server that understands EQL ... i.e., requiring some intermediary proxy service as in the REST example. It there a way to do that solely in the client cljs?


You can have Pathom running on the client.

Jakub Holý (HolyJak)21:04:50

All the live examples in the book do just that


Is it possible to re-order transactions that are in the processing queue?


@jatkin So, the tx system is pluggable. You can use txn_processing ns as a basis for whatever you want to plug in. So, the short answer to your question is: yes. The longer answer is that such reordering is not an included feature.


but the entry point to the whole thing is one function that can be set in application setup


Ok, cool. I think I'll take advantage of that. Thanks!


yeah, the existing thing is more complex than it needs to be, mostly to maintain compat with F2.


I’ve wanted to supply a simpler one, but then that affects the book, etc etc


a contrib lib with something simpler would be awesome 😉


Cool. I'm interested in contributing to the project, so if I come up with something that I can make publishable I'll let you know.


yeah, let me know if you need pointers. The core of tx processing just needs to turn a transact! into a series of optimistic actions, and network operations whose results are funneled back to the original mutation result handlers. You could make a very very simple one that processed the optimistic stuff during submission, and then submits the network stuff at the same time.


As a starting point, what kind of things are you thinking of simplifying? (nevermind :))


(see above) 😉


You can get the remote stuff off of each mutation as you process the optimistic side, and technically you could just submit a net request for each element as you go. That isn’t perfectly optimal for HTTP network traffic (but it would be perfectly fine for websockets)


It could be quite small, indeed


but of course such a tx system would lose support for things like ptransact!


(which in F3 land we’ve made it really unnecessary to need that function anymore)