Fork me on GitHub

Just added ptransact! to 2.0. See for some details (or better yet check out the 2.0 branch and run the devguide and play with the live card)


This new method is for pessimistic transactions. Combined with mutation return values it gives a sequential reasoning model to the full-stack interaction, allowing you to have mutations whose actions can check the result of a prior full-stack operation. This makes ui-blocking-until-server-is-done easier to implement when you need it. ptransact! is also safe to call from within a mutation, so you can deal with things like retries in a straightforward manner.


I’m working on some cool automation for this kind of things that is modern and fancy, but I recognize that some of you have a need to follow UI specifications from less-enlightened product managers 😉


There were a few really cool things about implementing this: 1. It only took about 72 new lines of code 2. It didn’t require callbacks or the introduction of async into our nice clean UI model 3. It satisfies the only (knock on wood) remaining commonly-needed technique that was “you have to do it yourself, and it is a bit of a pain” 4. The combination of the new mutation joins and this largely make a custom mutation-merge obsolete 5. We can now officially forget fallback was ever a thing…never liked that thing. It will continue to be supported, but will likely “get lost” from the documentation 😜


2.0.0-SNAPSHOT updated on clojars


Hello everyone.


I’m slowly trying to make my Fulcro app production ready and I stumbled upon this problem when trying to compile my project with the production settings (advanced compilation on):


I have this code in my client_main.cljs:


(reset! app (core/mount @app root/Root “app”))


In dev mode everything goes well


Maybe I need to setup correctly something before mounting?


I started my Fulcro app like this:


I really don’t know where to look at. It’s clear that the problem arises when mounting the app, but not why my :pages key is not setup. It’s my main router, which has a static route, the home page, already setup through the IntialAppState protocol


seems like a query issue somehow


Invalid join, {:pages nil}


@rastandy check your queries, it seems like something is getting bad on the way there


@wilkerlucio indeed, but when in dev mode, It works like a charm


The only change between dev and production is how the app is mounted. My project file is based on the fulcro-template’s one


can you send the piece that might have this? sometimes things change in prod


here is my project file:


and the dev user.cljs is almost the same as fulcro-template’s one:


the mounting phase in production should be triggered by this code instead:


sorry for cluttering the channel


I think I should try without optimization first


wow, things works when building with optimizations :none


now I’m in trouble


I realize I can walk and strip keys from data trees myself, but have you considered allowing the user to provide their own regex to match keys that are client only? I prefer to use auto namespaced keys when building widgets, and then spec those keys


@rastandy This is part of why you use the template…you’re almost certainly leaving your dev code that refreshes source (tools-namespace) while doing production build?


So, Om Next has this hack on the compiler that, if removed, breaks adv compilation in exactly this way. A call to set-refresh-dirs (which happens in Clojure) breaks the compiler (which runs in clojar) with respect to this hack.


Solution: Make a profile in your project file, production, that changes the source path to never include dev code or dependencies. If you look at the template this is well-commented. I agree it sucks. I pulled my hair out for days trying to figure that one out.


@uwo spec didn’t exist when that part of the lib was written. We could consider making that a hook. It happens rather deep in the bowels, but you can file an issue on it if you like. Even better, submit a PR 🙂 Mainly it will just be passing that function through the setup code, and defaulting it to the existing strip-ui


@rastandy I guess the only specific comment about it is in the project file of the template: My Om Next bug report is here: I’m not sure what to do about it…the design of defui itself is broken with respect to Closure optimizations (it’s the static thing)….possible this is a Closure bug that will get fixed. I’ve not analyzed it, but in Fulcro 2.0 this will obviously fall on me to fix.


If anyone likes compiler hacking, this would be a great contribution for 2.0: figure out how to not need the stuff in Fulcro 2.0 that hacks the compiler…I just opened my own issue on Fulcro:


This is very low on my priority list, because it has an easy workaround (for now)


Looking at your project file @rastandy it seems you already have the fix available to you. This should work: lein with-profile production cljsbuild once production


Hm…you also have the comment that tells you this…


and lein uberjar will do it for you


so if we have a query that requires running multiple datomic.api/qs and munging results, i.e. not a simple pull expression, I’ll need to use approaches detailed in!/fulcro_devguide.M45_Advanced_Server_Query_Processing ?


Fulcro 1.2.0 is now on clojars. Adds support for a tool registry, so that @wilkerlucio new inspect tool can auto-find your apps 🙂


also a few minor additions and tweaks


@uwo Numerous approaches. You can manually take the query apart, run a parser on it, assume you know what the query is and just respond to it, or use a library like pathom


but in general, yes, if you need to run multiple queries from a single incoming request, you’ll want something like a server-side parser to piece it together.


ha. I was about to say that was my first time hearing about pathom, but evidently not, since I have it bookmarked 🙂


any trick to tell something to load from remote once, but then used local version from there on out?


@tony.kay thank you very much for the explanation and for the solution. I confirm that “lein with-profile production cljsbuild once production” solved the problem


@tony.kay many, many thanks!


@uwo it is your state…how about (if thing-is-not-present? (load ...)) 😜 But seriously, do you mean something more complex somehow?


Haha. That would be too simple. Crikey, what a silly question on my part


pushed the wrong thing 😞


git flow hiccup there


don’t use 2.0.0-alpha1…it is really a mis-labeled 1.2.0


ok..I think I got it… Fulcro spec 2.0.0-alpha2 on clojars Fulcro 2.0.0-alpha2 also on clojars


combined ptransact! and compressible-transact! into just transact! as options. I didn’t want to change the API, but after looking at it, I didn’t really see a good enough reason not to.


about, I think we should not remove that, the ref allows for targeting a specific ident on the database while calling the transact, without having to be the actual component


oh right 😕 That sets ref for the mutations. I forgot about that


Hm. So, here’s the options: 1. Let people augment the transaction themselves: (transact! this (compressible-tx [(f)])) 2. Add a simple wrappers like compressible-transact! that just does the above 3. try to interpret the args (don’t like this one) I was doing (2), but thought I could drop the ref because I (incorrectly) remembered it just being a refresh optimization


I guess (2) was pretty good after all


also 1, the 2 can be derived from that if needed


the thing about (1) is that ptransact! is designed to be callable from within mutations


so it isn’t that simple


ok, I'm fine with any of those, just don't remove the ref please 🙂


ok, thanks for speaking up


no problem, thanks for letting us know it in the first place with the public sharing of thoughts through issues


so, I’ll push an alpha3 here in a moment that will revert back to the separately-named functions…have to fix the docs, too


I’ve revised the 2.0 milestone on github. I’m hoping to have the remaining items done by the 30th….or at least close enough. I’ve got a lot of the documentation touched up. Forms could still use some love, queries need testing, but may already be right…and then UI refresh could possibly be buggy (or over-rendering). History support is also not optimized, and could cause frame-rate performance issues, but that isn’t necessarily a show-stopper…it can be turned off.


So, my target is to release 2.0.0-beta1 on Nov. 30th, and merge it to develop where it becomes the primary branch of development.