Fork me on GitHub

@roklenarcic I could not reproduce your issue. I’m pushing 3.2.7 now. Perhaps you were having a SNAPSHOT update issue


btw does the :query propery of pre-merge parameter have query with or without the elided parts?


on my demo, the query in the params is: :query [:form/id :form/name {:com.fulcrologic.fulcro.algorithms.form-state/config [:com.fulcrologic.fulcro.algorithms.form-state/id :com.fulcrologic.fulcro.algorithms.form-state/fields :com.fulcrologic.fulcro.algorithms.form-state/complete? :com.fulcrologic.fulcro.algorithms.form-state/subforms :com.fulcrologic.fulcro.algorithms.form-state/pristine-state]}]


which obvs has the join to form config


elision from global-eql-transform happens one layer lower in the stack


the bug in 3.2.6 was that I was passing the wrong query to merge (and thus pre-merge)


I’ll try to put together a github repo that reproduces the bug and I will notify you when/if I have that


I have money on there not being a bug at this point. If you have an issue, it is either solved now, or it has to do with something specific you’re doing in configuration of the app or parameters passed to load itself.


If you have not fiddled with adv config, and are not passing query update params to load, then it should work


How can I find the source of errors like "ERROR [com.fulcrologic.fulcro.ui-state-machines:?] - #error {:message "Invalid expression [object Object]", :data {:type :error/invalid-expression}} Handler for event :com.fulcrologic.fulcro.ui-state-machines/started threw an exception for ASM ID :com.fulcrologic.rad.authorization/auth-machine"?


there is the pause on caught exceptions in chrome option:


if using state machines you can also enable verbose logging in chrome devtools


the state machine's internal logging calls will show up


I'm using fulcro-rad-demo


Maybe I should nuke everything and start from a clean slate


"Pause on caught exceptions" has it stop in react.development.js


idk, from your message it looks like the handler function of com.fulcrologic.rad.authorization/auth-machine prob received some data it didn't like


there may be some more details in the stack trace, but sometimes not because of asynchrony. for bugs where i don't have any ideas i'll start commenting out parts of the code until things works, and then add them back in until the bug is triggered to narrow down what part of the app is the source of the issue


has anyone dealt with a route target that you want to allow optional path params? ["page"] ["page" :number] seems to me like you'd need two components to handle this


You can also look into the RAD code where the started event is defined and add a println or something


i'd recommend this also: you can add a local alias in ~/.clojure/deps.edn (or equivalent location for windows)

:local-fulcro {:override-deps {com.fulcrologic/fulcro {:local/root "/Users/my-user/projects/fulcro"}}}
clone fulcro to that path and then enable the alias in your shadow-cljs.edn file


Or simply (in-ns '...) and eval your modified definition of the uism


@danvingo depends on what you mean by optional. To me that is two different routes…or you should pass something like :default for the :number parameter. DR doesn’t support optional path params.


It also isn’t the only solution…it just happens to be one I coded for you. Nothing keeps you from making your own routing system…lots of code to start from 😉


on will-enter the page component would read the params from the url and if it's missing use a default


ha, all good I just ran into this use case and was trying to come up with solutions


Is it really a hardship that you might have to use [“page” “default”] instead of [“page”]?


or that those few extra characters show up in the URL? (BTW, it would be easy for you to translate the latter into the former in code, and let the URL still be /page)


it's just UX


right, and D.R. has nothing to do with your UX 🙂


it just influences it


i'm still in the exploratory phase of all these parts so that's why i asked


you’re just one hand-written function away from (f URL) => dr-path


i don't understand all the pieces quite yet


so, there is convenience built into D.R. It is easy to translate between the routes you’d use in code and what you’d show on the URL. That is intentional. But it isn’t a UX requirement.


Fulcro 3.2.8 is on Clojars: I found and fixed a regression in component indexing. Also note that the versions between 3.2.0 and 3.2.5 or so have some subtle bugs I accidentally introduced with transaction processing. I’ve reverted those changes internally, and recommend version 3.1.22 (conservative) or 3.2.8+ if you want some of the newer tx features..

Eric Ihli21:05:58

I just came across a defn syntax that I've never seen before and don't understand. I posted this in #beginners thinking it might be a Clojure thing rather than a fulcro thing, but didn't find the answer there. What are the second vectors below the param vectors and above the body? Looking at, I expected to only see a pre/post map in that position. So what is this thing?

(defn default-tx!
  "Default (Fulcro-2 compatible) transaction submission. The options map can contain any additional options
  ([app tx]
   [::app ::txn/tx => ::txn/id]
   (default-tx! app tx {:optimistic? true}))
  ([{:keys [::runtime-atom] :as app} tx options]
   [:com.fulcrologic.fulcro.application/app ::txn/tx ::txn/options => ::txn/id]
   (txn/schedule-activation! app)
   ;;; ,,,


That function was a guardrails defn that I changed to plain defn, but I left the type sigs in place. They are no-ops


was trying to reduce the dev-time overhead of tx processing a bit, and checking those specs was a little heavy, and unlikely to break since it is an internal pass-through call.


Maybe a Guardrails thing


Defn variant from combining defn with Clojure Spec


Though I normally see it used as >defn?!

Eric Ihli21:05:34

It's a defn, not a >defn , and I don't see it rebound. Is it left over from a refactor and clojure doesn't treat it as a compiler error? Just a no-op?

Eric Ihli21:05:51

That's probably it. :thumbsup:


Hmm. Odd that it treats => as a no-op, since it is a macro