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?

@wilkerlucio Yes

@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

Cool!

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.

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 https://github.com/fulcrologic/fulcro/issues/55

@cjmurphy Great! Thanks for letting me know