This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (1)
- # beginners (102)
- # boot (5)
- # cljs-dev (59)
- # cljsjs (1)
- # clojure (154)
- # clojure-australia (1)
- # clojure-brasil (1)
- # clojure-dusseldorf (4)
- # clojure-greece (36)
- # clojure-italy (10)
- # clojure-poland (5)
- # clojure-romania (1)
- # clojure-russia (7)
- # clojure-spec (32)
- # clojure-uk (113)
- # clojure-ukraine (3)
- # clojurescript (107)
- # cursive (13)
- # data-science (25)
- # datomic (23)
- # emacs (3)
- # events (1)
- # fulcro (72)
- # funcool (10)
- # graphql (1)
- # leiningen (1)
- # luminus (2)
- # lumo (38)
- # off-topic (14)
- # onyx (78)
- # planck (4)
- # re-frame (55)
- # reagent (1)
- # ring (3)
- # ring-swagger (2)
- # rum (19)
- # shadow-cljs (89)
- # spacemacs (101)
- # sql (2)
- # unrepl (88)
ptransact! to 2.0. See https://github.com/fulcrologic/fulcro/blob/2.0/src/devguide/fulcro_devguide/H30_Server_Interactions_Error_Handling.cljs#L140 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 😜
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 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
@rastandy check your queries, it seems like something is getting bad on the way there
The only change between dev and production is how the app is mounted. My project file is based on the fulcro-template’s one
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
@rastandy I guess the only specific comment about it is in the project file of the template: https://github.com/fulcrologic/fulcro-template/blob/develop/project.clj#L28
My Om Next bug report is here: https://github.com/omcljs/om/issues/880
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: https://github.com/fulcrologic/fulcro/issues/67
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
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 https://fulcrologic.github.io/fulcro/guide.html#!/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 🙂
@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
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
@uwo it is your state…how about
(if thing-is-not-present? (load ...)) 😜 But seriously, do you mean something more complex somehow?
ok..I think I got it… Fulcro spec 2.0.0-alpha2 on clojars Fulcro 2.0.0-alpha2 also on clojars
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 https://github.com/fulcrologic/fulcro/issues/68, 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
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
the thing about (1) is that
ptransact! is designed to be callable from within mutations
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.