Fork me on GitHub

From my Java days IIRC Error is the type at the top of the hierarchy of Java exceptions. I'll try keeping the existing form but using :pre with Error rather than Exception.


Hmm - that doesn't help, still whatever is being passed in is something other than an Error even: java.lang.AssertionError: Assert failed: (instance? Error ex)


So (throw ex) gives a reasonable result (shows the underlying Datomic problem). But also having serialize-exception do nothing (return nil) ensures that the cause of the problem is not lost.


I've tried to find the type of ex, but code from within serialize-exception does not seem to be amenable to println, log/warn or log/error.


@tony.kay question, when you pulled the code from om to fulcro 2.0, you did it from master, right?


@currentoor I have not. I’ve tried a few libs, had success with about 20% of them.


@roklenarcic Fixed. On 1.1.0-SNAPSHOT on clojars


@cjmurphy Throwable is at the top, actually. I changed the code on develop and also pushed this with 1.1.0-SNAPSHOT to clojars. Let me know if that is better.


So, currently in Fulcro 1.0, because Om Next is underneath, one could augment the read local parser and technically trigger remote reads. This is not an advertised “feature”, but probably works (I’ve not tested it, but don’t see why it wouldn’t). This is possible useful for those porting from Om Next, but in 2.0 carrying around this legacy way of doing remote reads complicates things. Anyone see a good reason why I should continue supporting this local parser-based remote-read behavior?


nope, I think we can just discard it, IMO it's a very complex and hard to grasp method, specially if we can do cleanup without it


that’s my feeling as well


cool, I was asking about the version because some of my PR's that got merged there have things that I'm missing


glad to pull them in if I missed them


there are probably a number of pending PRs that would be useful, though there is a lot of simplification going on that may fix bugs


(and possibly create new ones 😕 )


@currentoor If you want to use npm-deps try shadow-cljs that basically fixes all issues with using external libraries


@mitchelkuijpers That’s nice to know. I was wondering about that.


I am fixing some stuf for it but it works very smart, it doe simple optimizations for your npm deps and also fixes a lot of issues with externs


And theller the maintainer is really helpfull


@mitchelkuijpers thanks I’ll give it a shot. It should result in a reduced build size right? Vs using cljsjs?


And it still does advanced compliation but only on your cljs code and not the external npm-deps


Yeah if you only import certain namespaces


trying to find the docs for tx-fallback, you guys remember where is it?


is there a way to have a post mutation after a regular mutation? (sounds very funky when it's out loud :P)


fallbacks are defined in data-fetch and mutations namespaces.


my problem is that I have a series of mutations, but I need the second one to run only if the first one succeed


currently it sends both at same time, giving no room to stop in the middle


Why can’t the server decide? E.g. why can’t you send both?


I guess it can be done by calling a mutation on a fulcro load, I ended up not needing it, but I feel way more confortable knowing the option is available if I need to


I hear you on the comfort…it bugs me as well…but I just have yet to see a case that really needed it. As soon as you admit logic to the tx chain, you’re in for a lot more complexity at the UI layer. You’re essentially asking for a tx with logic: (transact! this [(f) (when ok? (g))]), but you’re going to implement it through exposing async at the UI layer.


Seems like there are these cases: 1. remote mutation followed by local (conditional on first) 2. remote mutation followed by remote (conditional on first) (1) is trivial with mutation-merge (2) would require you to at least run a transact! from mutation merge (which is only OK if you defer it via setTimeout), or use a follow-on remote read with a post-mutation.


I’m still trying to get my head around what pattern should be used. I’m having trouble finding objective criteria on this.


I guess, technically, running (js/setTimeout (fn [] (transact! reconciler ...)) 0) is perfectly fine. It won’t “nest” the transaction since you’re deferring it to the next “idle time”. You can save your app off to an atom, so you can get at it at any time. So, from that perspective perhaps I just need to document that you may run transact! anywhere you want, as long as it is wrapped in this trick when you’re currently inside of another transaction’s processing.


I don’t think that sucks. Perhaps I add something to the API like inner-transact! or trigger! that is just that


that still moves us away from callbacks as the mechanism. Tracing isn’t so bad, because it is in the context of a sequence (which you’ll also see in the history)….and each tx is just data that appears in the history as well.


There are very limited places they would occur, and they’d still be directly navigable (assuming you put any mutation merge handler near the mutation it was merging)


jump into a mutation: you can see the inner trigger! calls, which you can nav to from there.


still gets them out of the UI layer, where we’re trying to preserve the illusion of no async


main down-side: they are not an immediately apparent part of the UI tx


But the other option of trying to embed logic in the tx somehow just sounds abhorrent


I have no idea what you mean about post mutations on regular ones…that’s called functional composition within the original mutation


@tony.kay Yes {:pre [(instance? Throwable ex)]} fixed the issue (I just changed that on my local version). Makes sense that the Datomic 'exception' I was having implemented Throwable.


If anyone is interested in (better) upcoming support for return values from mutations, please read/comment on


@cjmurphy Great! Thanks for letting me know