Fork me on GitHub
#fulcro
<
2017-11-22
>
tony.kay06:11:44

Just added 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)

tony.kay06:11:18

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.

tony.kay06:11:33

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 😉

tony.kay06:11:59

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 😜

tony.kay06:11:18

2.0.0-SNAPSHOT updated on clojars

rastandy11:11:28

Hello everyone.

rastandy11:11:44

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):

rastandy11:11:35

I have this code in my client_main.cljs:

rastandy11:11:36

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

rastandy11:11:47

In dev mode everything goes well

rastandy11:11:50

Maybe I need to setup correctly something before mounting?

rastandy11:11:58

I started my Fulcro app like this:

rastandy11:11:52

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

wilkerlucio12:11:41

seems like a query issue somehow

wilkerlucio12:11:49

Invalid join, {:pages nil}

wilkerlucio12:11:09

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

rastandy13:11:36

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

rastandy13:11:08

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

wilkerlucio13:11:16

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

rastandy13:11:03

here is my project file:

rastandy13:11:55

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

rastandy13:11:12

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

rastandy13:11:35

sorry for cluttering the channel

rastandy13:11:07

I think I should try without optimization first

rastandy13:11:02

wow, things works when building with optimizations :none

rastandy13:11:04

now I’m in trouble

uwo14:11:03

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

tony.kay16:11:24

@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?

tony.kay16:11:40

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.

tony.kay16:11:40

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.

tony.kay16:11:12

@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

tony.kay16:11:43

@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.

tony.kay16:11:27

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

tony.kay16:11:39

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

tony.kay16:11:20

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

tony.kay16:11:21

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

tony.kay16:11:35

and lein uberjar will do it for you

uwo16:11:31

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 ?

tony.kay16:11:38

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 🙂

tony.kay16:11:53

also a few minor additions and tweaks

tony.kay16:11:53

@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

tony.kay16:11:31

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.

uwo16:11:58

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

uwo17:11:22

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

rastandy17:11:13

@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

rastandy17:11:26

@tony.kay many, many thanks!

tony.kay17:11:47

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

uwo18:11:55

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

tony.kay19:11:53

pushed the wrong thing 😞

tony.kay19:11:13

git flow hiccup there

tony.kay19:11:59

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

tony.kay20:11:51

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

tony.kay20:11:14

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.

wilkerlucio20:11:19

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

tony.kay20:11:43

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

tony.kay20:11:29

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

tony.kay20:11:53

I guess (2) was pretty good after all

wilkerlucio20:11:21

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

tony.kay20:11:13

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

tony.kay20:11:19

so it isn’t that simple

wilkerlucio20:11:46

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

tony.kay20:11:57

ok, thanks for speaking up

wilkerlucio20:11:24

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

tony.kay20:11:17

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

tony.kay21:11:15

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.

tony.kay21:11:16

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.