Fork me on GitHub

I'm trying to get a modal working from react-modal (, but when I set up a workspace defcard, I get an Invalid join, {:ui/root nil} error. Google brought back nothing on that. I can post some of the code, but even a hint of what that error might mean would help.


The card shows up in the workspace UI, but fails to mount. Here's the stacktrace:

"Error: Invalid join, {:ui/root nil}
    at new cljs$core$ExceptionInfo ()
    at Function.cljs$core$IFn$_invoke$arity$3 ()
    at Function.cljs$core$IFn$_invoke$arity$2 ()
    at Object.fulcro$client$impl$parser$join__GT_ast [as join__GT_ast] ()
    at Object.fulcro$client$impl$parser$expr__GT_ast [as expr__GT_ast] ()
    at fulcro$client$impl$parser$parser_$_self_$_step ()
    at Object.cljs$core$IReduce$_reduce$arity$3 ()"

Lennart Buit05:06:58

I don’t know whether this could be related, but modals tend to use react portals, which are rendered elsewhere in the real dom than that they are rendered in the virtual:


I have a weird situation in Fulcro Inspect where the State after of my last transaction doesn't match with the DB. Could anyone take a guess at what could be causing that?


I have a few elements that mysteriously (at least to me) got removed from my DB. I can confirm that with the history slider. But when I try to use the transaction view to debug it, I can't find it there.


Doesn't post-mutations show up in the Transactions tab? I found the mysterious change and it was done in a post mutation step, which I can't seem to find any traces of in the Transactions tab.


@maxt are you on Fulcro 2 or Fulcro 3?


Wow we are just playing with Ghostwheel, How do people us this in Fulcro components? Would be pretty cool if you could just add ^::g/trace to a component to quickly see all the bindings


@robert.mather.rmm The error message means your join is invalid 😜 On your query. You have something in your root after [{:ui/root HERE}] that is returning nil.


@maxt Inspect is a chrome extension. It does not have access to your db. The client-preload watches the state atom and sends deltas to the extension (for speed). The diff algorithm is optimized for Fulcro normalized dbs, and also the data has to be serializable, or it just sends a placeholder for it. All sorts of things “could be” going wrong.


On post mutations: don’t remember…would have to look at the source. Most likely not: post mutations in F2 are a hack internally and not real mutations.


I don’t remember at the moment how I’ve addressed that in F3…pretty sure post mutations are real mutations there, with full support for everything (including remotes), which they cannot manage in 2


@mitchelkuijpers I personally use gw all over the place, but not in components…what would you like there? I personally have not even tried the tracing, because I mostly wanted it for consistent control of instrumentation and shorter notation. Be interested in your thoughts for F3. Are you suggesting the trace affect render?


Yes that is exactly what I mean


I just tried it out for a function and it is very handy to quickly spot bugs


But we just started using it last week, and the automatic outstrument is extremely usefull during development


yeah…other than I found a bug in it that makes it unusable in F3 😞


goes into an inf loop on certain multi-arity cases


submitted bug report…but have not had time to make a simple repro for them


Ah that sucks, is it solvable?


don’t know


Yeah that can take a lot of time


so, you realize that render is a js function getting just “this”


and that props and such are “hooked onto” that js object at string keys


would trace still do anything useful?


Ah yeah probably not


it looks at all the bindings in scope in a function


So that would make it really tough to use then


Not sure if it's pluggable somehow


yeah, the “bindings” are done in a manufactured let from the macro


(render [this] (let [props (prim/props this) ...] ...)) is what render looks like for real


Ah that might work


Not sure if it's pluggable, and or usefull enough


But maybe first try trace out, it is really handy


Sorry gotta go but will look at it, and think about it some more


It might work, it can also trace anonymous functions


cool, you can always fork the repo/macro and drop in metadata


So I played around and ran into a problem that Fulcro uses a 0.4.0-SNAPSHOT and there is no artifact for ghostwheel.tracer with the same version and 0.3.9 seems to not be compatible. But I found out that there is this macro in ghostwheel: And we could make a Option for Component where you can give it ::g/trace 3 and it wraps the render code inside of |>. Would you take a PR for that? Btw the codebase in Fulcro3 feels very simple when compared with Fulcro2


Yeah, all that Om Next complexity was just noise…nice to finally clean it up.


Sorry, I never responded to your question. The answer is “conditionally yes”: - The change has to be supported by his stubs library so it is elided when disabled. In fact, you can already do that as a “library concern” in Fulcro 3…see render-middleware option of app/fulcro-app.


but I’m also not opposed to it being in the core wrapping code for cljs render


Ah cool, will look at both options


But first I have to find a ghostwheel.trace 0.4.0-SNAPSHOT


But I cannot find a repository for it..


yeah, I don’t use trace (yet)…I needed 0.4.0 to get gw/>def, which allows me to easily elide specs when I elide ghostwheel.


shrinks code size a lot


Yeah I found that in the commit history, that is interesting


That is also very nice to create UI component specs for dev


Is the new fc3 template to be cloned or is it available as a lein template?


probably not maintaining a lein template anymore


I’m having to cut down how much I maintain. A lot of ancillary things like that are not of personal importance to my use of Fulcro…community maintenance will be required for such things

👍 16
Abhinav Sharma03:06:05

I do think that once a project has that initial push by the lead dev, it should be the entire community who takes up the task of maintaining and updating the ecosystem.

Abhinav Sharma03:06:05

I do think that once a project has that initial push by the lead dev, it should be the entire community who takes up the task of maintaining and updating the ecosystem.